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Prefacio 


Desde su primera edición en 2010, el material docente y el código fuente de los 
ejemplos del Curso de Experto en Desarrollo de Videojuegos, impartido en la 
Escuela Superior de Informática de Ciudad Real de la Universidad de Castilla-La 
Mancha, se ha convertido en un referente internacional en la formación de 
desarrolladores de videojuegos. 


Puedes obtener más información sobre el curso, así como los resultados de los 
trabajos creados por los alumnos de las ediciones anteriores en www.cedv.es. La 
versión electrónica de este libro (y del resto de libros de la colección) puede 
descargarse desde la web anterior. El libro «físico» puede adquirirse desde 
Amazon.es y Amazon.com 


Sobre este libro... 

Este libro forma parte de una colección de 
4 volúmenes, con un perfil técnico, 
dedicados al Desarrollo de Videojuegos: 











1. Arquitectura del Motor. Estudia los aspectos 
esenciales del diseño de un motor de videojuegos, 
así como las técnicas básicas de programación y 
patrones de diseño. dl 
Ela 
2. Programación Gráfica. El segundo libro ; 
se centra en algoritmos y técnicas de 
representación gráfica, así como en 
optimizaciones y simulación física. 


3. Técnicas Avanzadas. En este 
volumen se recogen aspectos avanzados, 
como estructuras de datos específicas y 
técnicas de validación. 


4. Desarrollo de Componentes. El 
último libro está dedicado a los 
componentes especificos del motor, 
como la Inteligencia Artificial, 
Networking o el Sonido y Multimedia. 


Requisitos previos 

Este libro tiene un público objetivo con un perfil principalmente técnico. Al igual 
que el curso, está orientado a la capacitación de profesionales de la programación de 
videojuegos. De esta forma, este libro no está orientado para un público de perfil 
artístico (modeladores, animadores, músicos, etc.) en el ámbito de los videojuegos. 


Se asume que el lector es capaz de desarrollar programas de nivel medio en C++. 
Aunque se describen algunos aspectos clave de C++ a modo de resumen, es 
recomendable refrescar los conceptos básicos con alguno de los libros recogidos en 
la bibliografía del curso. De igual modo, se asume que el lector tiene conocimientos 
de estructuras de datos y algoritmia. El libro está orientado principalmente para 
titulados o estudiantes de últimos cursos de Ingeniería en Informática. 


Programas y código fuente 

El código de los ejemplos puede descargarse en la siguiente página web: 
http://www.cedv.es. Salvo que se especifique explícitamente otra licencia, todos los 
ejemplos del libro se distribuyen bajo GPLv3. 
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Resumen 


El objetivo de este módulo, titulado «Arquitectura del Motor» dentro del Curso de 
Experto en Desarrollo de Videojuegos, es introducir los conceptos básicos relativos a las 
estructuras y principios de diseño y desarrollo comúnmente empleados en la creación de 
videojuegos. Para ello, uno de los principales objetivos es proporcionar una visión general 
de la arquitectura general de un motor de juegos. 


Dentro del contexto de esta arquitectura general se hace especial hincapié en aspectos 
como los subsistemas de bajo nivel, el bucle de juego, la gestión básica de recursos, como 
el sonido, y la gestión de la concurrencia. Para llevar a cabo una discusión práctica de 
todos estos elementos se hace uso del motor de renderizado Ogre3D. 


Por otra parte, en este primer módulo también se estudian los fundamentos del lengua- 
je de programación C++ como herramienta fundamental para el desarrollo de videojue- 
gos profesionales. Este estudio se complementa con una discusión en profundidad de una 
gran variedad de patrones de diseño y de la biblioteca STL. Además, también se realiza 
un recorrido por herramientas que son esenciales en el desarrollo de proyectos software 
complejos, como por ejemplo los sistemas de control de versiones, o procesos como la 
compilación o la depuración. 
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dial, rivalizando en presupuesto con las industrias cinematográfica y musical. En 

este capítulo se discute, desde una perspectiva general, el desarrollo de videojue- 
gos, haciendo especial hincapié en su evolución y en los distintos elementos involucrados 
en este complejo proceso de desarrollo. En la segunda parte del capítulo se introduce el 
concepto de arquitectura del motor, como eje fundamental para el diseño y desarrollo 
de videojuegos comerciales. 


A ctualmente, la industria del videojuego goza de una muy buena salud a nivel mun- 


1.1. El desarrollo de videojuegos 


1.1.1. La industria del videojuego. Presente y futuro 


Lejos han quedado los días desde el desarrollo 
de los primeros videojuegos, caracterizados princi- Elevideo Meco Pone de canada do? 
palmente por su simplicidad y por el hecho de estar mo uno de los primeros videojuegos de 


desarrollados completamente sobre hardware. la historia. Desarrollado por Atari en 


, od 1975, el juego iba incluido en la con- 
Debido a los distintos avances en el campo de la a Pone Se calcula que se ven- 


informática, no sólo a nivel de desarrollo software dieron unas 50.000 unidades. 

y capacidad hardware sino también en la aplicación 

de métodos, técnicas y algoritmos, la industria del videojuego ha evolucionado hasta lle- 
gar a cotas inimaginables, tanto a nivel de jugabilidad como de calidad gráfica. 


El primer videojuego 


La evolución de la industria de los videojuegos ha estado ligada a una serie de hi- 
tos, determinados particularmente por juegos que han marcado un antes y un después, 
o por fenómenos sociales que han afectado de manera directa a dicha industria. Juegos 
como Doom, Quake, Final Fantasy, Zelda, Tekken, Gran Turismo, Metal Gear, The Sims 
o World of Warcraft, entre otros, han marcado tendencia y han contribuido de manera 
significativa al desarrollo de videojuegos en distintos géneros. 
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Por otra parte, y de manera complementaria a la aparición de estas obras de arte, la 
propia evolución de la informática ha posibilitado la vertiginosa evolución del desarrollo 
de videojuegos. Algunos hitos clave son por ejemplo el uso de la tecnología poligonal 
en 3D [1] en las consolas de sobremesa, el boom de los ordenadores personales como 
plataforma multi-propósito, la expansión de Internet, los avances en el desarrollo de mi- 
croprocesadores, el uso de shaders programables [11], el desarrollo de motores de juegos 
o, más recientemente, la eclosión de las redes sociales y el uso masivo de dispositivos 
móviles. 


Por todo ello, los videojuegos se pueden encontrar en ordenadores personales, con- 
solas de juego de sobremesa, consolas portátiles, dispositivos móviles como por ejemplo 
los smartphones, o incluso en las redes sociales como medio de soporte para el entreteni- 
miento de cualquier tipo de usuario. Esta diversidad también está especialmente ligada a 
distintos tipos o géneros de videojuegos, como se introducirá más adelante en esta misma 
sección. 


La expansión del videojuego es tan relevante que actualmente se trata de una indus- 
tria multimillonaria capaz de rivalizar con las industrias cinematográfica y musical. Un 
ejemplo representativo es el valor total del mercado del videojuego en Europa, tanto a 
nivel hardware como software, el cual alcanzó la nada desdeñable cifra de casi 11.000 
millones de euros, con países como Reino Unido, Francia o Alemania a la cabeza. En este 
contexto, España representa el cuarto consumidor a nivel europeo y también ocupa una 
posición destacada dentro del ranking mundial. 


A pesar de la vertiginosa evolución de la industria del 
videojuego, hoy en día existe un gran número de retos 
que el desarrollador de videojuegos ha de afrontar a la 
hora de producir un videojuego. En realidad, existen re- 
tos que perdurarán eternamente y que no están ligados a 
la propia evolución del hardware que permite la ejecu- 
ción de los videojuegos. El más evidente de ellos es la 
necesidad imperiosa de ofrecer una experiencia de entre- 
tenimiento al usuario basada en la diversión, ya sea a tra- 
vés de nuevas formas de interacción, como por ejemplo la 
realidad aumentada o la tecnología de visualización 3D, 
a través de una mejora evidente en la calidad de los tí- 


Figura 1.1: El desarrollo y la inno- tyJos, o mediante innovación en aspectos vinculados a la 
vación en hardware también supone . cda 
jugabilidad. 


un pilar fundamental en la industria 
del videojuego. 





No obstante, actualmente la evolución de los video- 
juegos está estrechamente ligada a la evolución del hard- 
ware que permite la ejecución de los mismos. Esta evolución atiende, principalmente, a 
dos factores: 1) la potencia de dicho hardware y 11) las capacidades interactivas del mismo. 
En el primer caso, una mayor potencia hardware implica que el desarrollador disfrute de 
mayores posibilidades a la hora de, por ejemplo, mejorar la calidad gráfica de un título o 
de incrementar la IA (Inteligencia Artificial) de los enemigos. Este factor está vinculado al 
multiprocesamiento. En el segundo caso, una mayor riqueza en términos de interactivi- 
dad puede contribuir a que el usuario de videojuegos viva una experiencia más inmersiva 
(por ejemplo, mediante realidad aumentada) o, simplemente, más natural (por ejemplo, 
mediante la pantalla táctil de un smartphone). 


1.1. El desarrollo de videojuegos [3] 





Finalmente, resulta especialmente importante destacar la existencia de motores de 
juego (game engines), como por ejemplo Quake! o Unreal?, middlewares para el trata- 
miento de aspectos específicos de un juego, como por ejemplo la biblioteca Havok” para 
el tratamiento de la física, o motores de renderizado, como por ejemplo Ogre 3D [7]. Este 
tipo de herramientas, junto con técnicas específicas de desarrollo y optimización, meto- 
dologías de desarrollo, o patrones de diseño, entre otros, conforman un aspecto esencial 
a la hora de desarrollar un videojuego. Al igual que ocurre en otros aspectos relacionados 
con la Ingeniería del Software, desde un punto de vista general resulta aconsejable el uso 
de todos estos elementos para agilizar el proceso de desarrollo y reducir errores potencia- 
les. En otras palabras, no es necesario, ni productivo, reinventar la rueda cada vez que se 
afronta un nuevo proyecto. 


1.1.2. Estructura típica de un equipo de desarrollo 


El desarrollo de videojuegos comerciales es un Tiempo real 
proceso complejo debido a los distintos requisitos Ei id. 


que ha de satisfacer y a la integración de distintas juegos, el concepto de tiempo real es 
disciplinas que intervienen en dicho proceso. Des- muy importante para dotar de realismo 
de un punto de vista general, un videojuego es una a los juegos, pero no es tan estricto co- 
aplicación gráfica en tiempo real en la que existe 79 el concepto de Uempo tea! maneje 

. A os . . o en los sistemas críticos. 
una interacción explícita mediante el usuario y el 
propio videojuego. En este contexto, el concepto de tiempo real se refiere a la necesidad 
de generar una determinada tasa de frames o imágenes por segundo, típicamente 30 ó 
60, para que el usuario tenga una sensación continua de realidad. Por otra parte, la inter- 
acción se refiere a la forma de comunicación existente entre el usuario y el videojuego. 
Normalmente, esta interacción se realiza mediante joysticks o mandos, pero también es 
posible llevarla a cabo con otros dispositivos como por ejemplo teclados, ratones, cascos 
o incluso mediante el propio cuerpo a través de técnicas de visión por computador o de 
interacción táctil. 


A continuación se describe la estructura típica de un equipo de desarrollo atendiendo a 
los distintos roles que juegan los componentes de dicho equipo [5]. En muchos casos, y en 
función del número de componentes del equipo, hay personas especializadas en diversas 
disciplinas de manera simultánea. 


Los ingenieros son los responsables de diseñar e implementar el software que permite 
la ejecución del juego, así como las herramientas que dan soporte a dicha ejecución. 
Normalmente, los ingenieros se suelen clasificar en dos grandes grupos: 


= Los programadores del núcleo del juego, es decir, las personas responsables de 
desarrollar tanto el motor de juego como el juego propiamente dicho. 


= Los programadores de herramientas, es decir, las personas responsables de desa- 
rrollar las herramientas que permiten que el resto del equipo de desarrollo pueda 
trabajar de manera eficiente. 





http ://www.idsoftware.com/games/quake/quake/ 
http ://www.unrealengine.com/ 
http://www. havok.com 
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Figura 1.2: Visión conceptual de un equipo de desarrollo de videojuegos, considerando especialmente la parte 
de programación. 


De manera independiente a los dos grupos mencionados, los ingenieros se pueden 
especializar en una o en varias disciplinas. Por ejemplo, resulta bastante común encontrar 
perfiles de ingenieros especializados en programación gráfica o en scripting e IA. Sin 
embargo, tal y como se sugirió anteriormente, el concepto de ingeniero transversal es 
bastante común, particularmente en equipos de desarrollo que tienen un número reducido 
de componentes o con un presupuesto que no les permite la contratación de personas 
especializadas en una única disciplina. 


En el mundo del desarrollo de videojuegos, es 


General vs. Específico h : S 
bastante probable encontrar ingenieros senior res- 


En función del tamaño de una empre- 


sa de desarrollo de videojuegos, el ni- ponsables de supervisar el desarrollo desde un pun- 
vel de especialización de sus emplea- to de vista técnico, de manera independiente al di- 
dos es mayor o menor. Sin embargo, las seño y generación de código. No obstante, este tipo 
ofertas de trabajo suelen incluir diver- de roles suelen estar asociados a la supervisión téc- 


sas disciplinas de trabajo para facilitar 


su integración. nica, la gestión del proyecto e incluso a la toma de 


decisiones vinculadas a la dirección del proyecto. 
Así mismo, algunas compañías también pueden tener directores técnicos, responsables de 
la supervisión de uno o varios proyectos, e incluso un director ejecutivo, encargado de ser 
el director técnico del estudio completo y de mantener, normalmente, un rol ejecutivo en 
la compañía o empresa. 


Los artistas son los responsables de la creación de todo el contenido audio-visual del 
videojuego, como por ejemplo los escenarios, los personajes, las animaciones de dichos 
personajes, etc. Al igual que ocurre en el caso de los ingenieros, los artistas también se 
pueden especializar en diversas cuestiones, destacando las siguientes: 


= Artistas de concepto, responsables de crear bocetos que permitan al resto del equipo 
hacerse una idea inicial del aspecto final del videojuego. Su trabajo resulta especial- 
mente importante en las primeras fases de un proyecto. 


= Modeladores, responsables de generar el contenido 3D del videojuego, como por 
ejemplo los escenarios o los propios personajes que forman parte del mismo. 


1.1. El desarrollo de videojuegos [5] 





= Artistas de texturizado, responsables de crear las texturas o imágenes bidimensio- 
nales que formarán parte del contenido visual del juego. Las texturas se aplican 
sobre la geometría de los modelos con el objetivo de dotarlos de mayor realismo. 


= Artistas de iluminación, responsables de gestionar las fuentes de luz del videojuego, 
así como sus principales propiedades, tanto estáticas como dinámicas. 


= Animadores, responsables de dotar de movimientos a los personajes y objetos di- 
námicos del videojuego. Un ejemplo típico de animación podría ser el movimiento 
de brazos de un determinado carácter. 


= Actores de captura de movimiento, responsables de obtener datos de movimiento 
reales para que los animadores puedan integrarlos a la hora de animar los persona- 
jes. 


= Diseñadores de sonido, responsables de integrar los efectos de sonido del videojue- 
go. 


= Otros actores, responsables de diversas tareas como por ejemplo los encargados de 
dotar de voz a los personajes. 


Al igual que suele ocurrir con los ingenieros, existe el rol de artista senior cuyas 
responsabilidades también incluyen la supervisión de los numerosos aspectos vinculados 
al componente artístico. 


Los diseñadores de juego son los responsa- 


E ) ] Scripting e IA 
bles de diseñar el contenido del juego, destacan- 


El uso de lenguajes de alto nivel es bas- 


do la evolución del mismo desde el principio has- tantescomún en elidesarrollo. de videos 
ta el final, la secuencia de capítulos, las reglas del juegos y permite diferenciar claramen- 
juego, los objetivos principales y secundarios, etc. te la lógica de la aplicación y la propia 
Evidentemente, todos los aspectos de diseño están implementación. Una parte significati- 


: : Z : va de las desarrolladoras utiliza su pro- 
estrechamente ligados al propio género del mismo. bio lenguaje. de seripiing, -aurique exis- 


Por ejemplo, en un juego de conducción es tarea ten lenguajes ampliamente utilizados, 
de los diseñadores definir el comportamiento de los como son Lua o Python. 

coches adversarios ante, por ejemplo, el adelanta- 

miento de un rival. 


Los diseñadores suelen trabajar directamente con los ingenieros para afrontar diversos 
retos, como por ejemplo el comportamiento de los enemigos en una aventura. De hecho, es 
bastante común que los propios diseñadores programen, junto con los ingenieros, dichos 
aspectos haciendo uso de lenguajes de scripting de alto nivel, como por ejemplo Lua* o 
Python'. 


Como ocurre con las otras disciplinas previamente comentadas, en algunos estudios 
los diseñadores de juego también juegan roles de gestión y supervisión técnica. 


Finalmente, en el desarrollo de videojuegos también están presentes roles vinculados a 
la producción, especialmente en estudios de mayor capacidad, asociados a la planificación 
del proyecto y a la gestión de recursos humanos. En algunas ocasiones, los productores 
también asumen roles relacionados con el diseño del juego. Así mismo, los responsables 
de marketing, de administración y de soporte juegan un papel relevante. También resul- 
ta importante resaltar la figura de publicador como entidad responsable del marketing 
y distribución del videojuego desarrollado por un determinado estudio. Mientras algu- 
nos estudios tienen contratos permanentes con un determinado publicador, otros prefieren 
mantener una relación temporal y asociarse con el publicador que le ofrezca mejores con- 
diciones para gestionar el lanzamiento de un título. 





4http://www.lua.org 
Shttp://www.python.org 
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1.1.3. El concepto de juego 


Dentro del mundo del entretenimiento electrónico, un juego normalmente se suele 
asociar a la evolución, entendida desde un punto de vista general, de uno o varios perso- 
najes principales o entidades que pretenden alcanzar una serie de objetivos en un mundo 
acotado, los cuales están controlados por el propio usuario. Así, entre estos elementos 
podemos encontrar desde superhéroes hasta coches de competición pasando por equipos 
completos de fútbol. El mundo en el que conviven dichos personajes suele estar com- 
puesto, normalmente, por una serie de escenarios virtuales recreados en tres dimensiones 
y tiene asociado una serie de reglas que determinan la interacción con el mismo. 


De este modo, existe una interacción explícita entre el jugador o usuario de video- 
juegos y el propio videojuego, el cual plantea una serie de retos al usuario con el objetivo 
final de garantizar la diversión y el entretenimiento. Además de ofrecer este componente 
emocional, los videojuegos también suelen tener un componente cognitivo asociado, obli- 
gando a los jugadores a aprender técnicas y a dominar el comportamiento del personaje 
que manejan para resolver los retos o puzzles que los videojuegos plantean. 


Desde una perspectiva más formal, la mayoría 
de videojuegos suponen un ejemplo representativo 


Caída de frames 
Si el núcleo de ejecución de un juego 


no es capaz de mantener los fps a un ni- de lo que se define como aplicaciones gráficas o 
vel constante, el juego sufrirá una caí- renderizado en tiempo real [1], las cuales se de- 
da de frames en un momento determi- finen a su vez como la rama más interactiva de la 
nado. Este hecho se denomina común- Informática Gráfica. Desde un punto de vista abs- 


mente como ralentización. . ., Pa z 
tracto, una aplicación gráfica en tiempo real se basa 


en un bucle donde en cada iteración se realizan los siguientes pasos: 


= El usuario visualiza una imagen renderizada por la aplicación en la pantalla o dis- 
positivo de visualización. 


= El usuario actúa en función de lo que haya visualizado, interactuando directamente 
con la aplicación, por ejemplo mediante un teclado. 


= En función de la acción realizada por el usuario, la aplicación gráfica genera una 
salida u otra, es decir, existe una retroalimentación que afecta a la propia aplicación. 


En el caso de los videojuegos, este ciclo de visualización, actuación y renderizado 
ha de ejecutarse con una frecuencia lo suficientemente elevada como para que el usuario 
se sienta inmerso en el videojuego, y no lo perciba simplemente como una sucesión de 
imágenes estáticas. En este contexto, el frame rate se define como el número de imágenes 
por segundo, comúnmente fps, que la aplicación gráfica es capaz de generar. A mayor 
frame rate, mayor sensación de realismo en el videojuego. Actualmente, una tasa de 30 
Jps se considera más que aceptable para la mayoría de juegos. No obstante, algunos juegos 
ofrecen tasas que doblan dicha medida. 





Generalmente, el desarrollador de videojuegos ha de buscar un compromiso entre los 
Jps y el grado de realismo del videojuego. Por ejemplo, el uso de modelos con una 

Le alta complejidad computacional, es decir, con un mayor número de polígonos, o la 
integración de comportamientos inteligentes por parte de los enemigos en un juego, 
o NPC (Non-Player Character), disminuirá los fps. 











En otras palabras, los juegos son aplicaciones interactivas que están marcadas por el 
tiempo, es decir, cada uno de los ciclos de ejecución tiene un deadline que ha de cumplirse 
para no perder realismo. 


1.1. El desarrollo de videojuegos [7] 





Aunque el componente gráfico representa gran parte de la complejidad computacio- 
nal de los videojuegos, no es el único. En cada ciclo de ejecución, el videojuego ha de 
tener en cuenta la evolución del mundo en el que se desarrolla el mismo. Dicha evolu- 
ción dependerá del estado de dicho mundo en un momento determinado y de cómo las 
distintas entidades dinámicas interactúan con él. Obviamente, recrear el mundo real con 
un nivel de exactitud elevado no resulta manejable ni práctico, por lo que normalmente 
dicho mundo se aproxima y se simplifica, utilizando modelos matemáticos para tratar con 
su complejidad. En este contexto, destaca por ejemplo la simulación física de los propios 
elementos que forman parte del mundo. 


Por otra parte, un juego también está ligado al com- 
portamiento del personaje principal y del resto de entida- 
des que existen dentro del mundo virtual. En el ámbito 
académico, estas entidades se suelen definir como agen- 
tes (agents) y se encuadran dentro de la denominada si- 
mulación basada en agentes [10]. Básicamente, este tipo 
de aproximaciones tiene como objetivo dotar a los NPC 
con cierta inteligencia para incrementar el grado de rea- 
lismo de un juego estableciendo, incluso, mecanismos de 
cooperación y coordinación entre los mismos. Respecto 
al personaje principal, un videojuego ha de contemplar 
las distintas acciones realizadas por el mismo, conside- 
rando la posibilidad de decisiones impredecibles a priori 
y las consecuencias que podrían desencadenar. 





Figura 1.3: El motor de juego repre- 
senta el núcleo de un videojuego y 
determina el comportamiento de los 
En resumen, y desde un punto de vista general, el  Yistintos módulos que lo componen. 
desarrollo de un juego implica considerar un gran núme- 

ro de factores que, inevitablemente, incrementan la complejidad del mismo y, al mismo 
tiempo, garantizar una tasa de fps adecuada para que la inmersión del usuario no se vea 


afectada. 


1.1.4. Motor de juego 


Al igual que ocurre en otras disciplinas en el campo 
de la informática, el desarrollo de videojuegos se ha bene- 
ficiado de la aparición de herramientas que facilitan dicho 
desarrollo, automatizando determinadas tareas y ocultan- 
do la complejidad inherente a muchos procesos de bajo 
nivel. Si, por ejemplo, los SGBD han facilitado enorme- 
mente la gestión de persistencia de innumerables aplica- 
ciones informáticas, los motores de juegos hacen la vida 
más sencilla a los desarrolladores de videojuegos. 


Según [5], el término motor de juego surgió a me- 
diados de los años 90 con la aparición del famosísimo 
juego de acción en primera persona Doom, desarrollado Meira ds john Gamccta nio dé 
por la compañía id Software bajo la dirección de John ¡0% desarrolladores de juegos más 
Carmack'. Esta afirmación se sustenta sobre el hecho de importantes, en el Game Developer 
que Doom fue diseñado con una arquitectura orienta- Conference del año 2010. 
da a la reutilización mediante una separación adecuada 
en distintos módulos de los componentes fundamentales, como por ejemplo el sistema 
de renderizado gráfico, el sistema de detección de colisiones o el sistema de audio, y 
los elementos más artísticos, como por ejemplo los escenarios virtuales o las reglas que 
gobernaban al propio juego. 








http ://en.wikipedia.org/wiki/John_D._Carmack 
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Este planteamiento facilitaba enormemente la reutilización de software y el concepto 
de motor de juego se hizo más popular a medida que otros desarrolladores comenzaron 
a utilizar diversos módulos o juegos previamente licenciados para generar los suyos pro- 
pios. En otras palabras, era posible diseñar un juego del mismo tipo sin apenas modificar 
el núcleo o motor del juego, sino que el esfuerzo se podía dirigir directamente a la parte 
artística y a las reglas del mismo. 


Este enfoque ha ido evolucionando y se ha expandido, desde la generación de mods 
por desarrolladores independientes o amateurs hasta la creación de una gran variedad de 
herramientas, bibliotecas e incluso lenguajes que facilitan el desarrollo de videojuegos. 
A día de hoy, una gran parte de compañías de desarrollo de videojuego utilizan motores 
O herramientas pertenecientes a terceras partes, debido a que les resulta más rentable 
económicamente y obtienen, generalmente, resultados espectaculares. Por otra parte, esta 
evolución también ha permitido que los desarrolladores de un juego se planteen licenciar 
parte de su propio motor de juego, decisión que también forma parte de su política de 
trabajo. 


Obviamente, la separación entre motor de juego y juego nunca es total y, por una 
circunstancia u otra, siempre existen dependencias directas que no permiten la reusabili- 
dad completa del motor para crear otro juego. La dependencia más evidente es el genero 
al que está vinculado el motor de juego. Por ejemplo, un motor de juegos diseñado para 
construir juegos de acción en primera persona, conocidos tradicionalmente como shooters 
o shoot'em all, será difícilmente reutilizable para desarrollar un juego de conducción. 


Una forma posible para diferenciar un motor de juego y el software que representa 
a un juego está asociada al concepto de arquitectura dirigida por datos (data-driven 
architecture). Básicamente, cuando un juego contiene parte de su lógica o funcionamiento 
en el propio código (hard-coded logic), entonces no resulta práctico reutilizarla para otro 
juego, ya que implicaría modificar el código fuente sustancialmente. Sin embargo, si dicha 
lógica o comportamiento no está definido a nivel de código, sino por ejemplo mediante 
una serie de reglas definidas a través de un lenguaje de script, entonces la reutilización sí 
es posible y, por lo tanto, beneficiosa, ya que optimiza el tiempo de desarrollo. 


Como conclusión final, resulta relevante desta- 


Game engine tuning E , 4 
car la evolución relativa a la generalidad de los mo- 


Los motores de juegos se suelen adap- 


tar para cubrir las necesidades específi- tores de juego, ya que poco a poco están haciendo 
cas de un título y para obtener un mejor posible su utilización para diversos tipos de juegos. 
rendimiento. Sin embargo, el compromiso entre generalidad y 


optimalidad aún está presente. En otras palabras, a 
la hora de desarrollar un juego utilizando un determinado motor es bastante común per- 
sonalizar dicho motor para adaptarlo a las necesidades concretas del juego a desarrollar. 


1.1.5. Géneros de juegos 


Los motores de juegos suelen estar, generalmente, ligados a un tipo o género particular 
de juegos. Por ejemplo, un motor de juegos diseñado con la idea de desarrollar juegos de 
conducción diferirá en gran parte con respecto a un motor orientado a juegos de acción en 
tercera persona. No obstante, y tal y como se discutirá en la sección 1.2, existen ciertos 
módulos, sobre todo relativos al procesamiento de más bajo nivel, que son transversales 
a cualquier tipo de juego, es decir, que se pueden reutilizar en gran medida de manera 
independiente al género al que pertenezca el motor. Un ejemplo representativo podría 
ser el módulo de tratamiento de eventos de usuario, es decir, el módulo responsable de 
recoger y gestionar la interacción del usuario a través de dispositivos como el teclado, el 
ratón, el joystick o la pantalla táctil. Otros ejemplo podría ser el módulo de tratamiento 
del audio o el módulo de renderizado de texto. 
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A continuación, se realizará una descripción de los distintos géneros de juegos más 
populares atendiendo a las características que diferencian unos de otros en base al motor 
que les da soporte. Esta descripción resulta útil para que el desarrollador identifique los 
aspectos críticos de cada juego y utilice las técnicas de desarrollo adecuadas para obtener 
un buen resultado. 


Mercado de shooters Probablemente, el género de juegos más popu- 
Los: FPS (Einst Person Shooter) pozan lar ha sido y es el de los los denominados FPS, 
actualmente de un buen momento y, abreviado tradicionalmente como shooters, repre- 
como consecuencia de ello, el número sentado por juegos como Quake, Half-Life, Call of 
de títulos disponibles es muy elevado, Duty o Gears of War, entre muchos otros. En este 


ofreciendo una gran variedad al usua- 


Mehe género, el usuario normalmente controla a un per- 


sonaje con una vista en primera persona a lo largo 
de escenarios que tradicionalmente han sido interiores, como los típicos pasillos, pero que 
han ido evolucionando a escenarios exteriores de gran complejidad. 


to use the br 
cture 





Figura 1.5: Captura de pantalla del juego TremulousQ), licenciado bajo GPL y desarrollado sobre el motor de 
Quake III. 


Los FPS representan juegos con un desarrollo complejo, ya que uno de los retos prin- 
cipales que han de afrontar es la inmersión del usuario en un mundo hiperrealista que 
ofrezca un alto nivel de detalle, al mismo tiempo que se garantice una alta reacción de 
respuesta a las acciones del usuario. Este género de juegos se centra en la aplicación de 
las siguientes tecnologías [5]: 


= Renderizado eficiente de grandes escenarios virtuales 3D. 


= Mecanismo de respuesta eficiente para controlar y apuntar con el personaje. 
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= Detalle de animación elevado en relación a las armas y los brazos del personaje 
virtual. 


= Uso de una gran variedad de arsenal. 


= Sensación de que el personaje flota sobre el escenario, debido al movimiento del 
mismo y al modelo de colisiones. 


= NPC con un nivel de IA considerable y dotados de buenas animaciones. 


= Inclusión de opciones multijugador a baja escala, típicamente entre 32 y 64 juga- 
dores. 


Normalmente, la tecnología de renderizado de los FPS está especialmente optimiza- 
da atendiendo, entre otros factores, al tipo de escenario en el que se desarrolla el juego. 
Por ejemplo, es muy común utilizar estructuras de datos auxiliares para disponer de más 
información del entorno y, consecuentemente, optimizar el cálculo de diversas tareas. Un 
ejemplo muy representativo en los escenarios interiores son los árboles BSP (Binary Spa- 
ce Partitioning) (árboles de partición binaria del espacio) [1], que se utilizan para realizar 
una división del espacio físico en dos partes, de manera recursiva, para optimizar, por 
ejemplo, aspectos como el cálculo de la posición de un jugador. Otro ejemplo represen- 
tativo en el caso de los escenarios exteriores es el denominado occlusion culling [1], que 
se utiliza para optimizar el proceso de renderizado descartando aquellos objetos 3D que 
no se ven desde el punto de vista de la cámara, reduciendo así la carga computacional de 
dicho proceso. 


En el ámbito comercial, la familia de motores Quake, creados por 1d Software, se 
ha utilizado para desarrollar un gran número de juegos, como la saga Medal of Honor, e 
incluso motores de juegos. Hoy es posible descargar el código fuente de Quake, Quake 
II y Quake UI ” y estudiar su arquitectura para hacerse una idea bastante aproximada de 
cómo se construyen los motores de juegos actuales. 


Otra familia de motores ampliamente conocida es la de Unreal, juego desarrollado en 
1998 por Epic Games. Actualmente, la tecnología Unreal Engine se utiliza en multitud 
de juegos, algunos de ellos tan famosos como Gears of War. 


Más recientemente, la compañía Crytek ha permitido la descarga del CryENGINE 3 
SDK (Software Development Kit)? para propósitos no comerciales, sino principalmente 
académicos y con el objetivo de crear una comunidad de desarrollo. Este kit de desarrollo 
para aplicaciones gráficas en tiempo real es exactamente el mismo que el utilizado por la 
propia compañía para desarrollar juegos comerciales, como por ejemplo Crysis 2. 


Otro de los géneros más relevantes son los de- 
nominados juegos en tercera persona, donde el usua- 


Super Mario Bros 


El popular juego de Mario, diseñado en 


1985 por Shigeru Miyamoto, ha ven- rio tiene el control de un personaje cuyas acciones 
dido aproximadamente 40 millones de se pueden apreciar por completo desde el punto de 
juegos a nivel mundial. Según el libro vista de la cámara virtual. Aunque existe un gran 


de los Record Guinness, es una de los parecido entre este género y el de los FPS, los jue- 
juegos más vendidos junto a Tetris y a , S E 
la saga de Pokemon, gos en tercera persona hacen especial hincapié en 
la animación del personaje, destacando sus movi- 
mientos y habilidades, además de prestar mucha atención al detalle gráfico de la totalidad 
de su cuerpo. Ejemplos representativos de este género son Resident Evil, Metal Gear, 
Gears of War o Uncharted, entre otros. 





Thttp ://www.idsoftware.com/business/techdownloads 
Shttp ://mycryengine. com/ 
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Figura 1.6: Captura de pantalla del juego TurtlearenaB), licenciado bajo GPL y desarrollado sobre el motor de 
Quake III. 


Dentro de este género resulta importante destacar los juegos de plataformas, en los que 
el personaje principal ha de ir avanzado de un lugar a otro del escenario hasta alcanzar un 
objetivo. Ejemplos representativos son las sagas de Super Mario, Sonic o Donkey Kong. 
En el caso particular de los juegos de plataformas, el avatar del personaje tiene normal- 
mente un efecto de dibujo animado, es decir, no suele necesitar un renderizado altamente 
realista y, por lo tanto, complejo. En cualquier caso, la parte dedicada a la animación del 
personaje ha de estar especialmente cuidada para incrementar la sensación de realismo a 
la hora de controlarlo. 


En los juegos en tercera persona, los desarrolladores han de prestar especial atención 
a la aplicación de las siguientes tecnologías [5]: 


= Uso de plataformas móviles, equipos de escalado, cuerdas y otros modos de movi- 
miento avanzados. 


= Inclusión de puzzles en el desarrollo del juego. 


= Uso de cámaras de seguimiento en tercera persona centradas en el personaje y que 
posibiliten que el propio usuario las maneje a su antojo para facilitar el control del 
personaje virtual. 


= Uso de un complejo sistema de colisiones asociado a la cámara para garantizar que 
la visión no se vea dificultada por la geometría del entorno o los distintos objetos 
dinámicos que se mueven por el mismo. 
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Gráficos 3D Otro género importante está representado por 
Vira Fighter, Tanzado en 1993 potSe: los juegos de lucha, en los que, normalmente, dos 
ga y desarrollado por Yu Suzuki, se jugadores compiten para ganar un determinado nú- 


considera como el primer juego de lu- mero de combates minando la vida o stamina del 
cha E en soportar gráficos tridi- jugador contrario. Ejemplos representativos de jue- 
mensionales. 


gos de lucha son Virtua Fighter, Street Fighter, Tek- 
ken, o Soul Calibur, entre otros. Actualmente, los juegos de lucha se desarrollan normal- 
mente en escenarios tridimensionales donde los luchadores tienen una gran libertad de 
movimiento. Sin embargo, últimamente se han desarrollado diversos juegos en los que 
tanto el escenario como los personajes son en 3D, pero donde el movimiento de los mis- 
mos está limitado a dos dimensiones, enfoque comúnmente conocido como juegos de 
lucha de scroll lateral. 


Debido a que en los juegos de lucha la acción se centra generalmente en dos persona- 
jes, éstos han de tener una gran calidad gráfica y han de contar con una gran variedad de 
movimientos y animaciones para dotar al juego del mayor realismo posible. Así mismo, 
el escenario de lucha suele estar bastante acotado y, por lo tanto, es posible simplificar 
su tratamiento y, en general, no es necesario utilizar técnicas de optimización como las 
comentadas en el género de los FPS. Por otra parte, el tratamiento de sonido no resulta 
tan complejo como lo puede ser en otros géneros de acción. 


Los juegos del género de la lucha han de prestar atención a la detección y gestión de 
colisiones entre los propios luchadores, o entre las armas que utilicen, para dar una sen- 
sación de mayor realismo. Además, el módulo responsable del tratamiento de la entrada 
al usuario ha de ser lo suficientemente sofisticado para gestionar de manera adecuada las 
distintas combinaciones de botones necesarias para realizar complejos movimientos. Por 
ejemplo, juegos como Street Fighter IV incorporan un sistema de timing entre los distin- 
tos movimientos de un combo. El objetivo perseguido consiste en que dominar completa- 
mente a un personaje no sea una tarea sencilla y requiera que el usuario de videojuegos 
dedique tiempo al entrenaiento del mismo. 


Los juegos de lucha, en general, han estado ligados a la evolución de técnicas comple- 
jas de síntesis de imagen aplicadas sobre los propios personajes con el objetivo de mejorar 
al máximo su calidad y, de este modo, incrementar su realismo. Un ejemplo representa- 
tivo es el uso de shaders [11] sobre la armadura o la propia piel de los personajes que 
permitan implementar técnicas como el bump mapping [1], planteada para dotar a estos 
elementos de un aspecto más rugoso. 


Simuladores F1 Otro género representativo en el mundo de los 
A A IET videojuegos es la conducción, en el que el usua- 
Los simuladores de juegos de conduc- : 5 LS 

ción no sólo se utilizan para el en- rio controla a un vehículo que normalmente rivaliza 
tretenimiento doméstico sino también con más adversarios virtuales o reales para llegar a 
para que, por ejemplo, los pilotos de la meta en primera posición. En este género se sue- 


Fórmula-1 conozcan todos los entresi- le distinguir entre simuladores, como por ejemplo 
jos de los circuitos y puedan conocer- 


los al detalle antes de embarcarse en los Gran Turismo, y arcade, como por ejemplo Ridge 
entrenamientos reales. Racer o Wipe Out. 


Mientras los simuladores tienen como objetivo 
principal representar con fidelidad el comportamiento del vehículo y su interacción con 
el escenario, los juegos arcade se centran más en la jugabilidad para que cualquier tipo de 
usuario no tenga problemas de conducción. 
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Los juegos de conducción se caracterizan por la ne- 
cesidad de dedicar un esfuerzo considerable en alcanzar 
una calidad gráfica elevada en aquellos elementos cerca- 





Lo ES nos a la cámara, especialmente el propio vehículo. Ade- 

PA? más, este tipo de juegos, aunque suelen ser muy lineales, 

ps IN á o, á mantienen una velocidad de desplazamiento muy eleva- 
09 da, directamente ligada a la del propio vehículo. 


Al igual que ocurre en el resto de géneros previamen- 

¡E te comentados, existen diversas técnicas que pueden con- 

Figura 1.7: Captura de pantalla del tribuir a mejorar la eficiencia de este tipo de juegos. Por 

juego de conducción Tux Racing, li- ejemplo, suele ser bastante común utilizar estructuras de 

cenciado bajo GPL por Jasmin Patry. datos auxiliares para dividir el escenario en distintos tra- 

mos, con el objetivo de optimizar el proceso de renderiza- 

do o incluso facilitar el cálculo de rutas óptimas utilizando técnicas de IA [12]. También 

se suelen usar imágenes para renderizar elementos lejanos, como por ejemplo árboles, 
vallas publicitarias u otro tipo de elementos. 


Del mismo modo, y al igual que ocurre con los juegos en tercera persona, la cámara 
tiene un papel relevante en el seguimiento del juego. En este contexto, el usuario nor- 
malmente tiene la posibilidad de elegir el tipo de cámara más adecuado, como por ejem- 
plo una cámara en primera persona, una en la que se visualicen los controles del propio 
vehículo o una en tercera persona. 


Otro género tradicional son los juegos de estrategia, normalmente clasificados en 
tiempo real o RTS (Real-Time Strategy) y por turnos (turn-based strategy). Ejemplos 
representativos de este género son Warcraft, Command 4 Conquer, Comandos, Age of 
Empires o Starcraft, entre otros. Este tipo de juegos se caracterizan por mantener una 
cámara con una perspectiva isométrica, normalmente fija, de manera que el jugador tiene 
una visión más o menos completa del escenario, ya sea 2D o 3D. Así mismo, es bastante 
común encontrar un gran número de unidades virtuales desplegadas en el mapa, siendo 
responsabilidad del jugador su control, desplazamiento y acción. 


Teniendo en cuenta las características generales de 
este género, es posible plantear diversas optimizaciones. 
Por ejemplo, una de las aproximaciones más comunes en 
este tipo de juegos consiste en dividir el escenario en una 
rejilla o grid, con el objetivo de facilitar no sólo el em- 
plazamiento de unidades o edificios, sino también la pla- 
nificación de movimiento de un lugar del mapa a otro. 
Por otra parte, las unidades se suelen renderizar con una 
resolución baja, es decir, con un bajo número de polígo- l . » 
nos, con el objetivo de posibilitar el despliegue de un gran Figura 1.8: Captura de pantalla del 


número de unidades de manera simultánea. juego de estrategia en tiempo real O 


: ei y . ¿ A.D., licenciado bajo GPL por Wild- 
Finalmente, en los últimos años ha aparecido un géne-  fregames. 


ro de juegos cuya principal característica es la posibilidad 

de jugar con un gran número de jugadores reales al mismo tiempo, del orden de cientos o 
incluso miles de jugadores. Los juegos que se encuadran bajo este género se denominan 
comúnmente MMOG (Massively Multiplayer Online Game). El ejemplo más represen- 
tativo de este género es el juego World of Warcarft. Debido a la necesidad de soportar 
un gran número de jugadores en línea, los desarrolladores de este tipo de juegos han de 
realizar un gran esfuerzo en la parte relativa al networking, ya que han de proporcionar un 
servicio de calidad sobre el que construir su modelo de negocio, el cual suele estar basado 
en suscripciones mensuales o anuales por parte de los usuarios. 
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Al igual que ocurre en los juegos de estrategia, los MMOG suelen utilizar personajes 
virtuales en baja resolución para permitir la aparición de un gran número de ellos en 
pantalla de manera simultánea. 


Además de los distintos géneros mencionados en esta sección, existen algunos más 
como por ejemplo los juegos deportivos, los juegos de rol o RPG (Role-Playing Games) 
o los juegos de puzzles. 


Antes de pasar a la siguiente sección en la que se discutirá la arquitectura general 
de un motor de juego, resulta interesante destacar la existencia de algunas herramientas 
libres que se pueden utilizar para la construcción de un motor de juegos. Una de las más 
populares, y que se utilizará en el presente curso, es OGRE 3D”. Básicamente, OGRE es 
un motor de renderizado 3D bien estructurado y con una curva de aprendizaje adecuada. 
Aunque OGRE no se puede definir como un motor de juegos completo, sí que proporciona 
un gran número de módulos que permiten integrar funcionalidades no triviales, como 
iluminación avanzada o sistemas de animación de caracteres. 


1.2. Arquitectura del motor. Visión general 


En esta sección se plantea una visión general de la arquitectura de un motor de jue- 
gos [5], de manera independiente al género de los mismos, prestando especial importancia 
a los módulos más relevantes desde el punto de vista del desarrollo de videojuegos. 


Como ocurre con la gran mayoría de sistemas software que tienen una complejidad 
elevada, los motores de juegos se basan en una arquitectura estructurada en capas. De 
este modo, las capas de nivel superior dependen de las capas de nivel inferior, pero no de 
manera inversa. Este planteamiento permite ir añadiendo capas de manera progresiva y, lo 
que es más importante, permite modificar determinados aspectos de una capa en concreto 
sin que el resto de capas inferiores se vean afectadas por dicho cambio. 


A continuación, se describen los principales módulos que forman parte de la arquitec- 
tura que se expone en la figura 1.9. 


1.2.1. Hardware, drivers y sistema operativo 


La capa relativa al hardware está vinculada a la plataforma en la que se ejecutará 
el motor de juego. Por ejemplo, un tipo de plataforma específica podría ser una consola 
de juegos de sobremesa. Muchos de los principios de diseño y desarrollo son comunes a 
cualquier videojuego, de manera independiente a la plataforma de despliegue final. Sin 
embargo, en la práctica los desarrolladores de videojuegos siempre llevan a cabo opti- 
mizaciones en el motor de juegos para mejorar la eficiencia del mismo, considerando 
aquellas cuestiones que son específicas de una determinada plataforma. 


La capa de drivers soporta aquellos componentes software de bajo nivel que permi- 
ten la correcta gestión de determinados dispositivos, como por ejemplo las tarjetas de 
aceleración gráfica o las tarjetas de sonido. 


La capa del sistema operativo representa la ca- 


La arquitectura Cell p > . 
pa de comunicación entre los procesos que se eje- 


En arquitecturas más novedosas, como 


por ejemplo la arquitectura Cell usa- cutan en el mismo y los recursos hardware asocia- 
da en Playstation 3 y desarrollada por dos a la plataforma en cuestión. Tradicionalmente, 
Sony, Toshiba e 1BM, las optimizacio- en el mundo de los videojuegos los sistemas opera- 


nes aplicadas suelen ser más depen- 


dientes dela plelatoraa iaa tivos se compilan con el propio juego para producir 


un ejecutable. Sin embargo, las consolas de última 
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Subsistemas específicos de juego 


Subsistema 
de juego 


Networking Audio 


Herramientas Motor Interfaces 
de desarrollo de física de usuario 


Motor de 


rendering 





Gestor de recursos 


Subsistemas principales 


Capa independiente de la plataforma 





Figura 1.9: Visión conceptual de la arquitectura general de un motor de juegos. Esquema adaptado de la arqui- 
tectura propuesta en [5]. 


generación, como por ejemplo Sony Playstation 39 o Microsoft XBox 3609, incluyen un 
sistema operativo capaz de controlar ciertos recursos e incluso interrumpir a un juego en 
ejecución, reduciendo la separación entre consolas de sobremesa y ordenadores persona- 
les. 


1.2.2. SDKs y middlewares 


Al igual que ocurre en otros proyectos software, el desarrollo de un motor de jue- 
gos se suele apoyar en bibliotecas existentes y SDK para proporcionar una determinada 
funcionalidad. No obstante, y aunque generalmente este software está bastante optimi- 
zado, algunos desarrolladores prefieren personalizarlo para adaptarlo a sus necesidades 
particulares, especialmente en consolas de sobremesa y portátiles. 
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Un ejemplo representativo de biblioteca para 


APIs gráficas ; 
el manejo de estructuras de datos es STL (Stan- 


OpenGL y Direct3D son los dos ejem- 


plos más representativos de API (Ap- dard Template Library) 10. STL es una biblioteca de 
plication Program Interface)s gráficas plantillas estándar para C++, el cual representa a su 
que se utilizan en el ámbito comercial. vez el lenguaje más extendido actualmente para el 


La principal diferencia entre ambas es : : : E 
la estandarización, factor que tiene sus desarrollo de videojuegos, debido principalmente a 


ventajas y desventajas. su portabilidad y eficiencia. 


En el ámbito de los gráficos 3D, existe un gran 
número de bibliotecas de desarrollo que solventan determinados aspectos que son comu- 
nes a la mayoría de los juegos, como el renderizado de modelos tridimensionales. Los 
ejemplos más representativos en este contexto son las APIs gráficas OpenGL!' y Di- 
rect3D, mantenidas por el grupo Khronos y Microsoft, respectivamente. Este tipo de bi- 
bliotecas tienen como principal objetivo ocultar los diferentes aspectos de las tarjetas grá- 
ficas, presentando una interfaz común. Mientras OpenGL es multiplataforma, Direct3D 
está totalmente ligado a sistemas Windows. 


Otro ejemplo representativo de SDKs vinculados al desarrollo de videojuegos son 
aquellos que dan soporte a la detección y tratamiento de colisiones y a la gestión de 
la física de las distintas entidades que forman parte de un videojuego. Por ejemplo, en 
el ámbito comercial la compañía Havok!? proporciona diversas herramientas, entre las 
que destaca Havok Physics. Dicha herramienta representa la alternativa comercial más 
utilizada en el ámbito de la detección de colisiones en tiempo real y en las simulaciones 
físicas. Según sus autores, Havok Physics se ha utilizado en el desarrollo de más de 200 
títulos comerciales. 


Por otra parte, en el campo del Open Source, ODE (Open Dynamics Engine) 3D'* 
representa una de las alternativas más populares para simular dinámicas de cuerpo rígi- 
do [1]. 


Recientemente, la rama de la Inteligencia Artificial en los videojuegos también se 
ha visto beneficiada con herramientas que posibilitan la integración directa de bloques de 
bajo nivel para tratar con problemas clásicos como la búsqueda óptima de caminos entre 
dos puntos o la acción de evitar obstáculos. 


1.2.3. Capa independiente de la plataforma 


Gran parte de los juegos se desarrollan tenien- 
; - do en cuenta su potencial lanzamiento en diversas 

Aunque en teoría las herramientas mul- ; $ 

tiplataforma deberían abstraer de los plataformas. Por ejemplo, un título se puede desa- 


Abstracción funcional 


aspectos subyacentes a las mismas, co- rrollar para diversas consolas de sobremesa y para 
mo por ejemplo el sistema operativo, PC al mismo tiempo. En este contexto, es bastante 
en la práctica suele ser necesario rea- común encontrar una capa software que aisle al res- 
lizar algunos ajustos en función de la 10d : d dem Ñ 

plataforma existente en capas de nivel o de capas superiores de cualquier aspecto que sea 
inferior. dependiente de la plataforma. Dicha capa se suele 


denominar capa independiente de la plataforma. 


Aunque sería bastante lógico suponer que la capa inmediatamente inferior, es decir, 
la capa de SDKs y middleware, ya posibilita la independencia respecto a las platafor- 
mas subyacentes debido al uso de módulos estandarizados, como por ejemplo bibliotecas 
asociadas a C/C++, la realidad es que existen diferencias incluso en bibliotecas estanda- 
rizadas para distintas plataformas. 
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Algunos ejemplos representativos de módulos incluidos en esta capa son las bibliote- 
cas de manejo de hijos o los wrappers o envolturas sobre alguno de los módulos de la capa 
superior, como el módulo de detección de colisiones o el responsable de la parte gráfica. 


1.2.4. Subsistemas principales 


La capa de subsistemas principales está vinculada a todas aquellas utilidades o biblio- 
tecas de utilidades que dan soporte al motor de juegos. Algunas de ellas son específicas del 
ámbito de los videojuegos pero otras son comunes a cualquier tipo de proyecto software 
que tenga una complejidad significativa. 


A continuación se enumeran algunos de los subsistemas más relevantes: 


= Biblioteca matemática, responsable de proporcionar al desarrollador diversas uti- 
lidades que faciliten el tratamiento de operaciones relativas a vectores, matrices, 
cuaterniones u operaciones vinculadas a líneas, rayos, esferas y otras figuras geo- 
métricas. Las bibliotecas matemáticas son esenciales en el desarrollo de un motor 
de juegos, ya que éstos tienen una naturaleza inherentemente matemática. 


= Estructuras de datos y algoritmos, responsable de proporcionar una implemen- 
tación más personalizada y optimizada de diversas estructuras de datos, como por 
ejemplo listas enlazadas o árboles binarios, y algoritmos, como por ejemplo bús- 
queda u ordenación, que la encontrada en bibliotecas como STL. Este subsistema 
resulta especialmente importante cuando la memoria de la plataforma o plataformas 
sobre las que se ejecutará el motor está limitada (como suele ocurrir en consolas de 
sobremesa). 


= Gestión de memoria, responsable de garantizar la asignación y liberación de me- 
moria de una manera eficiente. 


= Depuración y logging, responsable de proporcionar herramientas para facilitar la 
depuración y el volcado de logs para su posterior análisis. 


1.2.5. Gestor de recursos 


Esta capa es la responsable de proporcionar una interfaz unificada para acceder a 
las distintas entidades software que conforman el motor de juegos, como por ejemplo la 
escena o los propios objetos 3D. En este contexto, existen dos aproximaciones principales 
respecto a dicho acceso: 1) plantear el gestor de recursos mediante un enfoque centralizado 
y consistente o 1i) dejar en manos del programador dicha interacción mediante el uso de 
archivos en disco. 


La figura 1.10 muestra una visión general de un gestor de recursos, representando una 
interfaz común para la gestión de diversas entidades como por ejemplo el mundo en el 
que se desarrolla el juego, los objetos 3D, las texturas o los materiales. 


En el caso particular de Ogre 3D [7], el gestor 


á (¿q A 
de recursos está representado por la clase denomi- 


El motor de rendering Ogre 3D está es- 


nada Ogre::ResourceManager, tal y como se puede crito en C++ y permite que el desarro- 
apreciar en la figura 1.11. Dicha clase mantiene di- llador se abstraiga de un gran número 
versas especializaciones, las cuales están ligadas a de aspectos relativos al desarrollo de 
las distintas entidades que a su vez gestionan dis- aplicaciones gráficas. Sin embargo, es 


necesario estudiar su funcionamiento y 


tintos aspectos en un juego, como por ejemplo las cómomtilizarió de manera adecuada. 


texturas (clase Ogre::TextureManager), los mode- 
los 3D (clase Ogre::MeshManager) o las fuentes de texto (clase Ogre::FontManager). En 
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Recurso Recurso 
esqueleto colisión 





Recurso Recurso Recurso Recurso 
modelo 3D textura material fuente 


Gestor de recursos 


Figura 1.10: Visión conceptual del gestor de recursos y sus entidades asociadas. Esquema adaptado de la arqui- 
tectura propuesta en [5]. 





el caso particular de Ogre 3D, la clase Ogre::ResourceManager hereda de dos clases, Re- 
sourceAlloc y Ogre::ScriptLoader, con el objetivo de unificar completamente las diversas 
gestiones. Por ejemplo, la clase Ogre::ScriptLoader posibilita la carga de algunos recur- 
sos, como los materiales, mediante scripts y, por ello, Ogre::ResourceManager hereda de 


dicha clase. 
Ogre::ScriptLoader 
ResourceAlloc Ogre::TextureManager 


Ogre::SkeletonManager 
Ogre::MeshManager 
Ogre::MaterialManager 
Ogre::GPUProgramManager 
Ogre::FontManager 


Ogre::CompositeManager 


Figura 1.11: Diagrama de clases asociado al gestor de recursos de Ogre 3D, representado por la clase 
Ogre::ResourceManager. 
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1.2.6. Motor de rendering 


Debido a que el componente gráfico es una parte fundamental de cualquier juego, 
junto con la necesidad de mejorarlo continuamente, el motor de renderizado es una de las 
partes más complejas de cualquier motor de juego. 


Al igual que ocurre con la propia arquitectura de un motor de juegos, el enfoque más 
utilizado para diseñar el motor de renderizado consiste en utilizar una arquitectura multi- 
capa, como se puede apreciar en la figura 1.12. 


A continuación se describen los principales módulos que forman parte de cada una de 
las capas de este componente. 


Front end 


Efectos visuales 


Scene graph/culling y optimizaciones 


Renderizado de bajo nivel 


Interfaz con el 


dispositivo gráfico 
. E Motor de rendering 





Figura 1.12: Visión conceptual de la arquitectura general de un motor de rendering. Esquema simplificado de 
la arquitectura discutida en [5]. 


La capa de renderizado de bajo nivel aglutina las distintas utilidades de renderizado 
del motor, es decir, la funcionalidad asociada a la representación gráfica de las distintas 
entidades que participan en un determinado entorno, como por ejemplo cámaras, primi- 
tivas de rendering, materiales, texturas, etc. El objetivo principal de esta capa reside pre- 
cisamente en renderizar las distintas primitivas geométricas tan rápido como sea posible, 
sin tener en cuenta posibles optimizaciones ni considerar, por ejemplo, qué partes de las 
escenas son visibles desde el punto de vista de la cámara. 


Esta capa también es responsable de gestionar la interacción con las APIs de progra- 
mación gráficas, como OpenGL o Direct3D, simplemente para poder acceder a los dis- 
tintos dispositivos gráficos que estén disponibles. Típicamente, este módulo se denomina 
interfaz de dispositivo gráfico (graphics device interface). 


[20] 


Capítulo 1 :: Introducción 





Shaders 


Un shader se puede definir como un 
conjunto de instrucciones software que 
permiten aplicar efectos de renderizado 
a primitivas geométricas. Al ejecutarse 
en las unidades de procesamiento gráfi- 
co (Graphic Processing Units - GPUs), 


Así mismo, en la capa de renderizado de ba- 
jo nivel existen otros componentes encargados de 
procesar el dibujado de distintas primitivas geomé- 
tricas, así como de la gestión de la cámara y los 
diferentes modos de proyección. En otras palabras, 
esta capa proporciona una serie de abstracciones 


para manejar tanto las primitivas geométricas como 
las cámaras virtuales y las propiedades vinculadas 
a las mismas. 


el rendimiento de la aplicación gráfica 
mejora considerablemente. 


Por otra parte, dicha capa también gestiona el estado del hardware gráfico y los sha- 
ders asociados. Básicamente, cada primitiva recibida por esta capa tiene asociado un ma- 
terial y se ve afectada por diversas fuentes de luz. Así mismo, el material describe la 
textura o texturas utilizadas por la primitiva y otras cuestiones como por ejemplo qué 
pixel y vertex shaders se utilizarán para renderizarla. 


La capa superior a la de renderizado de bajo nivel se denomina scene graph/culling 
y optimizaciones y, desde un punto de vista general, es la responsable de seleccionar 
qué parte o partes de la escena se enviarán a la capa de rendering. Esta selección, u 
optimización, permite incrementar el rendimiento del motor de rendering, debido a que 
se limita el número de primitivas geométricas enviadas a la capa de nivel inferior. 


Aunque en la capa de rendering sólo se dibujan las primitivas que están dentro del 
campo de visión de la cámara, es decir, dentro del viewport, es posible aplicar más opti- 
mizaciones que simplifiquen la complejidad de la escena a renderizar, obviando aquellas 
partes de la misma que no son visibles desde la cámara. Este tipo de optimizaciones son 
críticas en juegos que tenga una complejidad significativa con el objetivo de obtener tasas 
de frames por segundo aceptables. 


Una de las optimizaciones típicas consiste en 
hacer uso de estructuras de datos de subdivisión 
espacial para hacer más eficiente el renderizado, 
gracias a que es posible determinar de una manera 
rápida el conjunto de objetos potencialmente visi- 
bles. Dichas estructuras de datos suelen ser árboles, 
aunque también es posible utilizar otras alternati- 
vas. Tradicionalmente, las subdivisiones espaciales 
se conocen como scene graph (grafo de escena), 
aunque en realidad representan un caso particular de estructura de datos. 


Optiazación. 
Las optimizaciones son esenciales en 
el desarrollo de aplicaciones gráficas, 
en general, y de videojuegos, en parti- 
cular, para mejorar el rendimiento. Los 
desarrolladores suelen hacer uso de es- 
tructuras de datos auxiliares para apro- 
vecharse del mayor conocimiento dis- 
ponible sobre la propia aplicación. 


Por otra parte, en esta capa también es común integrar métodos de culling, como 
por ejemplo aquellos basados en utilizar información relevante de las oclusiones para 
determinar qué objetos están siendo solapados por otros, evitando que los primeros se 
tengan que enviar a la capa de rendering y optimizando así este proceso. 


Idealmente, esta capa debería ser independiente de la capa de renderizado, permi- 
tiendo así aplicar distintas optimizaciones y abstrayéndose de la funcionalidad relativa al 
dibujado de primitivas. Un ejemplo representativo de esta independencia está representa- 
do por OGRE (Object-Oriented Graphics Rendering Engine) y el uso de la filosofía plug 
« play, de manera que el desarrollador puede elegir distintos diseños de grafos de escenas 
ya implementados y utilizarlos en su desarrollo. 
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Sobre la capa relativa a las optimizaciones se 


Filosofía Plug € Play ne 6 ] 
sitúa la capa de efectos visuales, la cual proporcio- 


Esta filosofía se basa en hacer uso de 


un componente funcional, hardware o na soporte a distintos efectos que, posteriormente, 
software, sin necesidad de configurar se puedan integrar en los juegos desarrollados ha- 
ni de modificar el funcionamiento de ciendo uso del motor. Ejemplos representativos de 
otros componentes asociados al prime- módulos que se incluyen en esta capa son aquéllos 


ro. . . y 
responsables de gestionar los sistemas de partículos 


(humo, agua, etc), los mapeados de entorno o las sombras dinámicas. 


Finalmente, la capa de front-end suele estar vinculada a funcionalidad relativa a la 
superposición de contenido 2D sobre el escenario 3D. Por ejemplo, es bastante común 
utilizar algún tipo de módulo que permita visualizar el menú de un juego o la interfaz 
gráfica que permite conocer el estado del personaje principal del videojuego (inventario, 
armas, herramientas, etc). En esta capa también se incluyen componentes para reproducir 
vídeos previamente grabados y para integrar secuencias cinemáticas, a veces interacti- 
vas, en el propio videojuego. Este último componente se conoce como IGC (In-Game 
Cinematics) system. 


1.2.7. Herramientas de depuración 


Debido a la naturaleza intrínseca de un video- 
juego, vinculada a las aplicaciones gráficas en tiem- 


Versiones beta 
Además del uso extensivo de herra- 


po real, resulta esencial contar con buenas herra- mientas de depuración, las desarro- 
mientas que permitan depurar y optimizar el propio lladoras de videojuegos suelen liberar 
motor de juegos para obtener el mejor rendimien- versiones betas de los mismos para que 
to posible. En este contexto, existe un gran número 10 Propias isnanos Pontibujan da la 


de herramientas de este tipo. Algunas de ellas son OAIECEIn de PUES 


herramientas de propósito general que se pueden utilizar de manera externa al motor de 
juegos. Sin embargo, la práctica más habitual consiste en construir herramientas de pro- 
filing, vinculadas al análisis del rendimiento, o depuración que estén asociadas al propio 
motor. Algunas de las más relevantes se enumeran a continuación [5]: 


= Mecanismos para determinar el tiempo empleado en ejecutar un fragmento especí- 
fico de código. 


= Utilidades para mostrar de manera gráfica el rendimiento del motor mientras se 
ejecuta el juego. 


= Utilidades para volcar logs en ficheros de texto o similares. 


= Herramientas para determinar la cantidad de memoria utilizada por el motor en 
general y cada subsistema en particular. Este tipo de herramientas suelen tener dis- 
tintas vistas gráficas para visualizar la información obtenida. 


= Herramientas de depuración que gestionan el nivel de información generada. 


= Utilidades para grabar eventos particulares del juego, permitiendo reproducirlos 
posteriormente para depurar bugs. 
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1.2.8. Motor de física 


ED auxiliares La detección de colisiones en un videojuego 
Aloma qUe oe en pre y su posterior tratamiento resultan esenciales para 
mo la obtención de la posición de un dotar de realismo al mismo. Sin un mecanismo de 
enemigo en el mapa, el uso exten- detección de colisiones, los objetos se traspasarían 
sivo de estructuras de datos auxilia- unos a otros y no sería posible interactuar con ellos. 


te perio ebienE So ore po Un ejemplo típico de colisión está representado en 
blemas computacionalmente comple- 


jos. La gestión de colisiones es otro los juegos de conducción por el choque entre dos o 

proceso que se beneficia de este tipo de más vehículos. Desde un punto de vista general, el 

técnicas. sistema de detección de colisiones es responsable 
de llevar a cabo las siguientes tareas [1]: 


1. La detección de colisiones, cuya salida es un valor lógico indicando si hay o no 
colisión. 


2. La determinación de la colisión, cuya tarea consiste en calcular el punto de inter- 
sección de la colisión. 


3. La respuesta a la colisión, que tiene como objetivo determinar las acciones que se 
generarán como consecuencia de la misma. 


Debido a las restricciones impuestas por la naturaleza de tiempo real de un video- 
juego, los mecanismos de gestión de colisiones se suelen aproximar para simplificar la 
complejidad de los mismos y no reducir el rendimiento del motor. Por ejemplo, en algu- 
nas ocasiones los objetos 3D se aproximan con una serie de líneas, utilizando técnicas de 
intersección de líneas para determinar la existancia o no de una colisión. También es bas- 
tante común hacer uso de árboles BSP para representar el entorno y optimizar la detección 
de colisiones con respecto a los propios objetos. 


Por otra parte, algunos juegos incluyen sistemas realistas o semi-realistas de simu- 
lación dinámica. En el ámbito de la industria del videojuego, estos sistemas se suelen 
denominar sistema de física y están directamente ligados al sistema de gestión de colisio- 
nes. 


Actualmente, la mayoría de compañías utilizan motores de colisión/física desarrolla- 
dos por terceras partes, integrando estos kits de desarrollo en el propio motor. Los más 
conocidos en el ámbito comercial son Havok, el cual representa el estándar de facto en 
la industria debido a su potencia y rendimiento, y PhysX, desarrollado por NVIDIA e 
integrado en motores como por ejemplo el Unreal Engine 3. 


En el ámbito del open source, uno de los más utilizados es ODE. Sin embargo, en este 
curso se hará uso del motor de simulación física Bullet!*, el cual se utiliza actualmente en 
proyectos tan ambiciosos como la suite 3D Blender. 


1.2.9. Interfaces de usuario 


En cualquier tipo de juego es necesario desarrollar un módulo que ofrezca una abs- 
tracción respecto a la interacción del usuario, es decir, un módulo que principalmente sea 
responsable de procesar los eventos de entrada del usuario. Típicamente, dichos even- 
tos estarán asociados a la pulsación de una tecla, al movimiento del ratón o al uso de un 
joystick, entre otros. 
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Desde un punto de vista más general, el módulo de interfaces de usuario también es 
responsable del tratamiento de los eventos de salida, es decir, aquellos eventos que pro- 
porcionan una retroalimentación al usuario. Dicha interacción puede estar representada, 
por ejemplo, por el sistema de vibración del mando de una consola o por la fuerza ejer- 
cida por un volante que está siendo utilizado en un juego de conducción. Debido a que 
este módulo gestiona los eventos de entrada y de salida, se suele denominar comúnmente 
componente de entrada/salida del jugador (player 1/O component). 


El módulo de interfaces de usuario actúa como un puente entre los detalles de bajo ni- 
vel del hardware utilizado para interactuar con el juego y el resto de controles de más alto 
nivel. Este módulo también es responsable de otras tareas importantes, como la asocación 
de acciones o funciones lógicas al sistema de control del juego, es decir, permite asociar 
eventos de entrada a acciones lógicas de alto nivel. 


En la gestión de eventos se suelen utilizar patrones de diseño como el patrón delegate 
[4], de manera que cuando se detecta un evento, éste se traslada a la entidad adecuada 
para llevar a cabo su tratamiento. 


1.2.10. Networking y multijugador 


La mayoría de juegos comerciales desarrollados en la actualidad incluyen modos de 
juegos multijugador, con el objetivo de incrementar la jugabilidad y duración de los tí- 
tulos lanzados al mercado. De hecho, algunas compañías basan el modelo de negocio de 
algunos de sus juegos en el modo online, como por ejemplo World of Warcraft de Bliz- 
zard Entertainment, mientras algunos títulos son ampliamente conocidos por su exitoso 
modo multijugador online, como por ejemplo la saga Call of Duty de Activision. 


Aunque el modo multijugador de un juego pue- 


. 04 . La 
de resultar muy parecido a su versión single-player, A ——————— 


El retraso que se produce desde que se 


en la práctica incluir el soporte de varios jugadores, envía un paquete de datos por una enti- 
ya sea online o no, tiene un profundo impacto en dad hasta que otra lo recibe se conoce 
diseño de ciertos componentes del motor de juego, como lag. En el ámbito de los video- 
como por ejemplo el modelo de objetos del juego, juegos, el lag se suele medir en milési- 


. > Ñ s de s do. 
el motor de renderizado, el módulo de entrada/sali- ed 


da o el sistema de animación de personajes, entre otros. De hecho, una de las filosofías 
más utilizadas en el diseño y desarrollo de motores de juegos actuales consiste en tratar 
el modo de un único jugador como un caso particular del modo multijugador. 


Por otra parte, el módulo de networking es el responsable de informar de la evolución 
del juego a los distintos actores o usuarios involucrados en el mismo mediante el envío de 
paquetes de información. Típicamente, dicha información se transmite utilizando sockets. 
Con el objetivo de reducir la latencia del modo multijugador, especialmente a través de 
Internet, sólo se envía/recibe información relevante para el correcto funcionamiento de 
un juego. Por ejemplo, en el caso de los FPS, dicha información incluye típicamente la 
posición de los jugadores en cada momento, entre otros elementos. 


1.2.11. Subsistema de juego 


El subsistema de juego, conocido por su término en inglés gameplay, integra todos 
aquellos módulos relativos al funcionamiento interno del juego, es decir, aglutina tanto 
las propiedades del mundo virtual como las de los distintos personajes. Por una parte, 
este subsistema permite la definición de las reglas que gobiernan el mundo virtual en el 
que se desarrolla el juego, como por ejemplo la necesidad de derrotar a un enemigo antes 
de enfrentarse a otro de mayor nivel. Por otra parte, este subsistema también permite la 
definición de la mecánica del personaje, así como sus objetivos durante el juego. 
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Este subsistema sirve también como capa de aislamiento entre las capas de más bajo 
nivel, como por ejemplo la de rendering, y el propio funcionamiento del juego. Es decir, 
uno de los principales objetivos de diseño que se persiguen consiste en independizar la 
lógica del juego de la implementación subyacente. Por ello, en esta capa es bastante co- 
mún encontrar algún tipo de sistema de scripting o lenguaje de alto nivel para definir, por 
ejemplo, el comportamiento de los personajes que participan en el juego. 


Diseñando juegos La capa relativa al subsistema de juego mane- 
Lodi de lean ja conceptos como el mundo del juego, el cual se 


juego, e incluso del comportamiento de refiere a los distintos elementos que forman parte 
los personajes y los NPCs, suelen do- del mismo, ya sean estáticos o dinámicos. Los ti- 
minar perfectamente los lenguajes de pos de objetos que forman parte de ese mundo se 
SEHpl, yO qUe-son sy BRnsipal ena suelen denominar modelo de objetos del juego [5]. 
mienta para llevar a cabo su tarea. . 4 m3 A 
Este modelo proporciona una simulación en tiempo 
real de esta colección heterogénea, incluyendo 


= Elementos geométricos relativos a fondos estáticos, como por ejemplo edificios o 
carreteras. 


= Cuerpos rígidos dinámicos, como por ejemplo rocas o sillas. 
= El propio personaje principal. 

= Los personajes no controlados por el usuario (NPCs). 

= Cámaras y luces virtuales. 


= Armas, proyectiles, vehículos, etc. 


Sistema de alto nivel del juego 


Sistema de scripting 


Objetos Objetos Simulación Sistema de 
estáticos dinámicos basada en agentes eventos 


Subsistema de juego 





Figura 1.13: Visión conceptual de la arquitectura general del subsistema de juego. Esquema simplificado de la 
arquitectura discutida en [5]. 


El modelo de objetos del juego está intimamente ligado al modelo de objetos software 
y se puede entender como el conjunto de propiedades del lenguaje, políticas y convencio- 
nes utilizadas para implementar código utilizando una filosofía de orientación a objetos. 
Así mismo, este modelo está vinculado a cuestiones como el lenguaje de programación 
empleado o a la adopción de una política basada en el uso de patrones de diseño, entre 
otras. 
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En la capa de subsistema de juego se integra el sistema de eventos, cuya principal 
responsabilidad es la de dar soporte a la comunicación entre objetos, independientemente 
de su naturaleza y tipo. Un enfoque típico en el mundo de los videojuegos consiste en 
utilizar una arquitectura dirigida por eventos, en la que la principal entidad es el evento. 
Dicho evento consiste en una estructura de datos que contiene información relevante de 
manera que la comunicación está precisamente guiada por el contenido del evento, y no 
por el emisor o el receptor del mismo. Los objetos suelen implementar manejadores de 
eventos (event handlers) para tratarlos y actuar en consecuencia. 


Por otra parte, el sistema de scripting permite modelar fácilmente la lógica del juego, 
como por ejemplo el comportamiento de los enemigos o NPCs, sin necesidad de volver 
a compilar para comprobar si dicho comportamiento es correcto o no. En algunos casos, 
los motores de juego pueden seguir en funcionamiento al mismo tiempo que se carga un 
nuevo script. 


Finalmente, en la capa del subsistema de juego es posible encontrar algún módulo 
que proporcione funcionalidad añadida respecto al tratamiento de la IA, normalmente de 
los NPCs. Este tipo de módulos, cuya funcionalidad se suele incluir en la propia capa de 
software específica del juego en lugar de integrarla en el propio motor, son cada vez más 
populares y permiten asignar comportamientos preestablecidos sin necesidad de progra- 
marlos. En este contexto, la simulación basada en agentes [18] cobra especial relevancia. 


Este tipo de módulos pueden incluir aspectos relativos a problemas clásicos de la IA, 
como por ejemplo la búsqueda de caminos óptimos entre dos puntos, conocida como 
pathfinding, y típicamente vinculada al uso de algoritmos A* [12]. Así mismo, también 
es posible hacer uso de información privilegiada para optimizar ciertas tareas, como por 
ejemplo la localización de entidades de interés para agilizar el cálculo de aspectos como 
la detección de colisiones. 


1.2.12. Audio 


Tradicionalmente, el mundo del desarrollo de videojuegos siempre ha prestado más 
atención al componente gráfico. Sin embargo, el apartado sonoro de un juego es espe- 
cialmente importante para que el usuario se sienta inmerso en el mismo y es crítico para 
acompañar de manera adecuada el desarrollo de dicho juego. Por ello, el motor de audio 
ha ido cobrando más y más relevancia. 


Asimismo, la aparición de nuevos formatos de audio de alta definición y la populari- 
dad de los sistemas de cine en casa han contribuido a esta evolución en el cada vez más 
relevante apartado sonoro. 


Actualmente, al igual que ocurre con otros componentes de la arquitectura del motor 
de juego, es bastante común encontrar desarrollos listos para utilizarse e integrarse en el 
motor de juego, los cuales han sido realizados por compañías externas a la del propio 
motor. No obstante, el apartado sonoro también requiere modificaciones que son especí- 
ficas para el juego en cuestión, con el objetivo de obtener un alto de grado de fidelidad y 
garantizar una buena experiencia desde el punto de visto auditivo. 


[26] Capítulo 1 :: Introducción 





1.2.13. Subsistemas específicos de juego 


Por encima de la capa de subsistema de juego y otros componentes de más bajo ni- 
vel se sitúa la capa de subsistemas específicos de juego, en la que se integran aquellos 
módulos responsables de ofrecer las características propias del juego. En función del tipo 
de juego a desarrollar, en esta capa se situarán un mayor o menor número de módulos, 
como por ejemplo los relativos al sistema de cámaras virtuales, mecanismos de IA espe- 
cíficos de los personajes no controlados por el usuario (NPCs), aspectos de renderizados 
específicos del juego, sistemas de armas, puzzles, etc. 


Idealmente, la línea que separa el motor de juego y el propio juego en cuestión estaría 
entre la capa de subsistema de juego y la capa de subsistemas específicos de juego. 


Capítulo 
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a los desarrolladores de videojuegos, y de aplicaciones en general, aumentar su 
productividad a la hora de construir software, gestionar los proyectos y recursos, 
así como automatizar procesos de construcción. 


A ctualmente, existen un gran número de aplicaciones y herramientas que permiten 


En este capítulo, se pone de manifiesto la importancia de la gestión en un proyecto 
software y se muestran algunas de las herramientas de desarrollo más conocidas en sis- 
temas GNU/Linux. La elección de este tipo de sistema no es casual. Por un lado, se trata 
de Software Libre, lo que permite a desarrolladores poder estudiar, aprender y entender 
hasta el más mínimo detalle de lo que hace el código de las herramientas que utiliza para 
desarrollar. Por otro lado, probablemente sea el mejor sistema operativo para construir y 
desarrollar aplicaciones debido al gran número de herramientas que proporciona. Es un 
sistema hecho por programadores para programadores. 


2.1. Introducción 


En la construcción de software no trivial, las herramientas de gestión de proyectos y de 
desarrollo facilitan la labor de las personas que lo construyen. A medida que el software 
se va haciendo más complejo y se espera más funcionalidad de él, se hace necesario el uso 
de herramientas que permitan automatizar los procesos del desarrollo, así como la gestión 
del proyecto y su documentación. 


Además, dependiendo del contexto, es posible que existan otros integrantes del pro- 
yecto que no tengan formación técnica y que necesiten realizar labores sobre el producto 
tales como traducciones, pruebas, diseño gráfico, marketing, etc. 
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Los videojuegos son proyectos software que, normalmente, requieren la participación 
de varias personas con diferentes perfiles profesionales (programadores, diseñadores grá- 
ficos, compositores de sonidos, etc.). Cada uno de ellos, trabaja con diferentes tipos de 
datos y con diferentes tipos de formatos. Todas las herramientas que permitan la cons- 
trucción automática del proyecto, la integración de sus diferentes componentes y la coor- 
dinación de sus miembros serán de gran ayuda en un entorno tan heterogéneo. 


Desde el punto de vista de la gestión del proyecto, una 
tarea esencial es la automatización del proceso de compi- 
lación y de construcción de los programas. Una de las ta- 
reas que más frecuentemente se realizan mientras se desa- 
rrolla y depura un programa es precisamente la de compi- 
lación y construcción. Cuanto más grande y complejo sea 
un programa, mayor es el tiempo que se necesita en esta 
fase y, por tanto, mayor tiempo consumirá. Un proceso 
automático de construcción de software ahorrará muchas 
pérdidas de tiempo en el futuro. 





En los sistemas GNU/Linux es habitual el uso de he- 
Figura 2.1: El proyecto GNU pro-  rramientas como el compilador GCC, el sistema de cons- 
porciona una gran abanico de herra- trucción GNU Make y el depurador GDB. Todas ellas fue- 
Ap de desarrollo y son utiliza ron creadas en el proyecto GNU y orientadas a la creación 
os en proyectos software de todo ti- e E 

po. de programas en C/C++, aunque también pueden ser uti- 

lizadas con otras tecnologías. También existen editores de 
texto como GNU Emacs o vi, y modernos (pero no por ello mejores) entornos de desarro- 
llo como Eclipse que no sólo facilitan las labores de escritura de código, sino que propor- 
cionan numerosas herramientas auxiliares dependiendo del tipo de proyecto. Por ejemplo, 
Eclipse puede generar los archivos Makefiles necesarios para automatizar el proceso de 
construcción con GNU Make. 


2.2. Compilación, enlazado y depuración 


La compilación y la depuración y, en general, el pro- 
ceso de construcción es una de las tareas más importantes 
desde el punto de vista del desarrollador de aplicaciones 
escritas en C/C++. En muchas ocasiones, parte de los pro- 
blemas en el desarrollo de un programa vienen originados 
directa o indirectamente por el propio proceso de cons- 
trucción del mismo. Hacer un uso indebido de las opcio- 
nes del compilador, no depurar utilizando los programas 
adecuados o realizar un incorrecto proceso de construc- 
ción del proyecto son ejemplos típicos que, en muchas 
ocasiones, consumen demasiado tiempo en el desarro- 
llo. Por todo ello, tener un conocimiento sólido e invertir 
tiempo en estas cuestiones ahorra más de un quebradero 
Figura 2%: G06 26m seletción de cabeza 8 mucho dinero) a lo largo del ciclo de vida de 
de compiladores para lenguajes co- la Aplicación. 


moy Hiro En esta sección se estudia una terminología y concep- 

tos básicos en el ámbito de los procesos de construcción 
de aplicaciones. Más específicamente, se muestra el uso del compilador de C/C++ GCC, 
el depurador GDB y el sistema de construcción automático GNU Make. 
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2.2.1. Conceptos básicos 


A la hora de buscar y compartir información con el resto de compañeros de profesión 
es necesario el uso de una terminología común. En las tareas de construcción del software 
existen algunos términos que son importantes conocer. 


Código fuente, código objeto y código ejecutable 


Como es de suponer, la programación consiste en escribir programas. Los programas 
son procedimientos que, al ejecutarse de forma secuencial, se obtienen unos resultados. 
En muchos sentidos, un programa es como una receta de cocina: una especificación se- 
cuencial de las acciones que hay que realizar para conseguir un objetivo. Cómo de abs- 
tractas sean estas especificaciones es lo que define el nivel de abstracción de un lenguaje. 


Los programas se pueden escribir directamente en código ejecutable, también llama- 
do código binario o código máquina. Sin embargo, el nivel de abstracción tan bajo que 
ofrecen estos lenguajes haría imposible que muchos proyectos actuales pudieran llevarse 
a cabo. Este código es el que entiende la máquina donde se va a ejecutar el programa y 
es específico de la plataforma. Por ejemplo, máquinas basadas en la arquitectura PC no 
ofrecen el mismo repertorio de instrucciones que otras basadas en la arquitectura PPC o 
ARM. A la dificultad de escribir código de bajo nivel se le suma la característica de no ser 
portable. 


Por este motivo se han creado los compiladores. Estos programas traducen código 
fuente, programado en un lenguaje de alto nivel, en el código ejecutable para una plata- 
forma determinada. Un paso intermedio en este proceso de compilación es la generación 
de código objeto, que no es sino código en lenguaje máquina al que le falta realizar el 
proceso de enlazado. Veremos este proceso con más detalle más adelante. 


Aunque en los sistemas como GNU/Linux la extensión en el nombre de los archivos 
es puramente informativa, los archivos fuente en C++ suelen tener las extensiones .cpp, 
.cc, y .h, .hh O .hpp para las cabeceras. Por su parte, los archivos de código objeto tienen 
extensión .o y lo ejecutables no suelen tener extensión. 


Compilador 


Como ya se ha dicho, se trata de un programa que, a partir del código fuente, genera 
el código ejecutable para la máquina destino. Este proceso de traducción automatizado 
permite al programador, entre otras muchas ventajas: 


= No escribir código de muy bajo nivel. 


= Detectar errores y sólo generar código «correcto». Como veremos, los compilado- 
res no pueden garantizar que nuestro programa sea correcto en todos los sentidos. 


= Abstraerse de la características propias de la máquina tales como registros especia- 
les, modos de acceso a memoria, etc. 


= Escribir código portable. Basta con que exista un compilador en una plataforma 
que soporte C++ como lenguaje de entrada para que se puedan portar programas a 
dicha plataforma. 


Aunque la función principal del compilador es la de actuar como traductor entre dos 
tipos de lenguaje, este término se reserva a los programas que transforman de un lenguaje 
de alto nivel a otro; por ejemplo, el programa que transforma código C++ en Java. 
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Existen muchos compiladores comerciales de C++ como Borland C++, Microsoft Vi- 
sual C++. Sin embargo, GCC es un compilador libre y gratuito que soporta C/C++ (entre 
otros lenguajes) y es ampliamente utilizado en muchos sectores de la informática: desde 
la programación gráfica a los sistemas empotrados. 

Obviamente, existen grandes diferencias entre las implementaciones de los compi- 
ladores de C++ disponibles. Estas diferencias vienen determinadas por el contexto de 
aplicación (por ejemplo, para sistemas empotrados) o por el propio fabricante. Sin em- 
bargo, es posible extraer una estructura funcional común como muestra la figura 2.3, que 
representa las fases de compilación en las que, normalmente, está dividido el proceso de 
compilación. 
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Figura 2.3: Fases de compilación 


Las fases están divididas en dos grandes bloques: 


= Frontend: o frontal del compilador. Es el encargado de realizar el análisis léxico, 
sintáctico y semántico de los ficheros de entrada. El resultado de esta fase es un 
código intermedio que es independiente de la plataforma destino. 


= Backend: el código intermedio pasa por el optimizador y es mejorado utilizan- 
do diferentes estrategias como la eliminación de código muerto o de situaciones 
redundantes. Finalmente, el código intermedio optimizado lo toma un generador 
de código máquina específico de la plataforma destino. Además de la generación, 
en esta fase también se realizan algunas optimizaciones propias de la plataforma 
destino. 


En definitiva, el proceso de compilación está dividido en etapas bien diferenciadas, 
que proporcionan diferente funcionalidad a las etapas subsiguientes hasta llegar a la ge- 
neración final de código ejecutable. 
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Enlazador 


A medida que los programas crecen se hace necesario poder separarlos en módulos, es 
decir, unidades independientes con sentido en el dominio de la aplicación y relacionadas 
unas con otras. Esto permite que un gran proyecto pueda ser más mantenible y manejable 
que si no existiera forma alguna de dividir funcionalmente un programa. Los módulos 
pueden tener dependencias entre sí (por ejemplo, el módulo A necesita B y C para funcio- 
nar) y la comprobación y resolución de estas dependencias corren a cargo del enlazador. 
El enlazador toma como entrada el código objeto. 


Bibliotecas 


Una de las principales ventajas del software es la reutilización del código. Normal- 
mente, los problemas pueden resolverse utilizando código ya escrito anteriormente y la 
reutilización del mismo se vuelve un aspecto clave para el tiempo de desarrollo del pro- 
ducto. Las bibliotecas ofrecen una determinada funcionalidad ya implementada para que 
sea utilizada por programas. Las bibliotecas se incorporan a los programas durante el 
proceso de enlazado. 


Las bibliotecas pueden enlazarse contra el programa de dos formas: 


= Estáticamente: en tiempo de enlazado, se resuelven todas las dependencias y sím- 
bolos que queden por definir y se incorpora al ejecutable final. 


La principal ventaja de utilizar enlazado estático es que el ejecutable puede con- 
siderarse standalone y es completamente independiente. El sistema donde vaya a 
ser ejecutado no necesita tener instaladas bibliotecas externas de antemano. Sin 
embargo, el código ejecutable generado tiene mayor tamaño. 


= Dinámicamente: en tiempo de enlazado sólo se comprueba que ciertas dependen- 
cias y símbolos estén definidos, pero no se incorpora al ejecutable. Será en tiempo 
de ejecución cuando se realizará la carga de la biblioteca en memoria. 


El código ejecutable generado es mucho menor, pero el sistema debe tener la bi- 
blioteca previamente instalada. 


En sistemas GNU/Linux, las bibliotecas ya compiladas suelen encontrarse en /usr/lib 
y siguen un convenio para el nombre: libnombre. Las bibliotecas dinámicas tienen exten- 
sión .so (shared object) y las estáticas .a. 


2.2.2. Compilando con GCC 


Desde un punto de vista estricto, GCC no es un compilador. GNU Compiler Collection 
(GCC) es un conjunto de compiladores que proporciona el proyecto GNU para diferentes 
lenguajes de programación tales como C, C++, Java, FORTRAN, etc. Dentro de este con- 
junto de compiladores, g++ es el compilador para C++. Teniendo en cuenta esta precisión, 
es común llamar simplemente GCC al compilador de C y C++, por lo que se usarán de 
forma indistinta en este texto. 


En esta sección se introducen la estructura bá- distec 
sica del compilador GCC, así como algunos de sus compilación modalary portalezde 
componentes y su papel dentro del proceso de com- GCC permite que herramientas como 
pilación. Finalmente, se muestran ejemplos de có- distcc puedan realizar compilaciones 
mo utilizar GCC (y otras herramientas auxiliares) distribuidas en red y en paralelo. 


para construir un ejecutable, una biblioteca estática 
y una dinámica. 
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2.2.3. ¿Cómo funciona GCC? 


GCC es un compilador cuya estructura es muy similar a la presentada en la sec- 
ción 2.2.1. Sin embargo, cada una de las fases de compilación la realiza un componente 
bien definido e independiente. Concretamente, al principio de la fase de compilación, se 
realiza un procesamiento inicial del código fuente utilizando el preprocesador GNU CPP, 
posteriormente se utiliza GNU Assembler para obtener el código objeto y, con la ayuda 
del enlazador GNU 1d, se crea el binario final. 


En la figura 2.4 se muestra un esquema general de los componentes de GCC que parti- 
cipan en el proceso. El hecho de que esté dividido en estas etapas permite una compilación 
modular, es decir, cada fichero de entrada se transforma a código objeto y con la ayuda del 
enlazador se resuelven las dependencias que puedan existir entre ellos. A continuación, 
se comenta brevemente cada uno de los componentes principales. 
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Figura 2.4: Proceso de compilación en GCC 
Preprocesador 


El preprocesamiento es la primera transformación que sufre un programa en C/C++. 
Se lleva a cabo por el GNU CPP y, entre otras, realiza las siguientes tareas: 


= Inclusión efectiva del código incluido por la directiva +tinclude. 
= Resuelve de las directivas +tifdef/+tifndef para la compilación condicional. 


= Sustitución efectiva de todas las directivas de tipo +define. 


La opción de -E de GCC detiene la compilación justo después del preprocesamiento. 
El preprocesador se puede invocar directamente utilizando la orden cpp. Como ejercicio 
se reserva al lector observar qué ocurre al invocar al preprocesador con el siguiente frag- 
mento de código. ¿Se realizan comprobaciones lexícas, sintáticas o semánticas? Utiliza 
los parámetros que ofrece el programa para definir la macro DEFINED_IT. 
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Htinclude <iostream> 
fídefine SAY_HELLO "Hi, world!" 


Htifdef DEFINED_IT 
fiwarning "If you see this message, you DEFINED_IT" 
*Hendif 


using namespace std; 
Code here?? 


int main() 4 
cout << SAY_HELLO << endl; 
return 0; 


) 


Compilación 


El código fuente, una vez preprocesado, se compila a lenguaje ensamblador, es decir, 
a una representación de bajo nivel del código fuente. Originalmente, la sintaxis de este 
lenguaje es la de AT8£T pero desde algunas versiones recientes también se soporta la 
sintaxis de Intel. 


Entre otras muchas operaciones, en la compilación se realizan las siguientes opera- 
ciones: 


= Análisis sintáctico y semántico del programa. Pueden ser configurados para obtener 
diferentes mensajes de advertencia (warnings) a diferentes niveles. 


= Comprobación y resolución de símbolos y dependencias a nivel de declaración. 
= Realizar optimizaciones. 


Utilizando GCC con la opción -S puede detenerse el proceso de compilación hasta la 
generación del código ensamblador. Como ejercicio, se propone cambiar el código fuente 
anterior de forma que se pueda construir el correspondiente en ensamblador. 





GCC proporciona diferentes niveles de optimizaciones (opción -0). Cuanto mayor 
es el nivel de optimización del código resultante, mayor es el tiempo de compila- 

uy ción pero suele hacer más eficiente el código de salida. Por ello, se recomienda no 
optimizar el código durante las fases de desarrollo y sólo hacerlo en la fase de dis- 
tribución/instalación del software. 











Ensamblador 


Una vez se ha obtenido el código ensamblador, GNU Assembler es el encargado de 
realizar la traducción a código objeto de cada uno de los módulos del programa. Por 
defecto, el código objeto se genera en archivos con extensión .o y la opción -c de GCC 
permite detener el proceso de compilación en este punto. 


GNU Assembler forma parte de la distribución GNU Binutils y se corresponde con el 
programa as. Como ejercicio, se propone al lector modificar el código ensamblador obte- 
nido en la fase anterior sustituyendo el mensaje original "Hi, world" por "Hola, mundo". 
Intenta generar el código objeto asociado utilizando directamente el ensamblador (no 
GCC). 
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Enlazador 


GNU Linker también forma parte de la distribución GNU Binutils y se corresponde 
con el programa 1d. Con todos los archivos objetos el enlazador (linker) es capaz de 
generar el ejecutable o código binario final. Algunas de las tareas que se realizan en el 
proceso de enlazado son las siguientes: 


= Selección y filtrado de los objetos necesarios para la generación del binario. 
= Comprobación y resolución de símbolos y dependencias a nivel de definición. 


= Realización del enlazado (estático y dinámico) de las bibliotecas. 


Como ejercicio se propone utilizar el linker directamente con el código objeto ge- 
nerado en el apartado anterior. Nótese que las opciones -1 y -L sirven para añadir rutas 
personalizadas a las que por defecto 1d utiliza para buscar bibliotecas. 


2.2.4. Ejemplos 


Como se ha mostrado, el proceso de compilación está compuesto por varias fases bien 
diferenciadas. Sin embargo, con GCC se integra todo este proceso de forma que, a partir 
del código fuente se genere el binario final. 


En esta sección se mostrarán ejemplos en los que se crea un ejecutable al que, poste- 
riormente, se enlaza con una biblioteca estática y otra dinámica. 


Compilación de un ejecutable 


Como ejemplo de ejecutable se toma el siguiente programa. 


Listado 2.2: Programa básico de ejemplo 


ttinclude <iostream> 


using namespace std; 


1 

2 

3 

4 

5 class Square ( 
6 private: 

7 int side_; 

8 

9 public: 

10 Square(int side_length) : side (side_length) ( ); 
11 int getArea() const [ return side *side_; ); 


12 ); 

13 

14 int main () € 

15 Square square(5); 

16 cout << "Area: " << square.getArea() << endl; 


17 return 0; 
18 ) 
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En C++, los programas que generan un ejecutable deben tener definida la función 
main, que será el punto de entrada de la ejecución. El programa es trivial: se define una 


clase Square que representa a un cuadrado. Ésta implementa un método getArea() que 
devuelve el área del cuadrado. 


Suponiendo que el archivo que contiene el código fuente se llama main. cpp, para cons- 
truir el binario utilizaremos g++, el compilador de C++ que se incluye en GCC. Se podría 
utilizar gcc y que se seleccionara automáticamente el compilador. Sin embargo, es una 
buena práctica utilizar el compilador correcto: 


$ g++ -o main main.cpp 


Nótese que todo el proceso de compilación se ha realizado automáticamente y cada 
una de las herramientas auxiliares se han ejecutado internamente en su momento oportuno 
(preprocesamiento, compilación, ensamblado y enlazado). La opción -o indica a GCC el 
nombre del archivo de salida de la compilación. 


Podríamos hacer el proceso anterior por partes: primero generando el código objeto y 
el código ejecutable de la siguiente forma: 


$ g++ -c main.o 
$ g++ main.o -o main 


Aquí, la segunda llamada de g++ invoca implícitamente al enlazador 1d. Utiliza la 
opción -v de GCC para ver en detalle qué órdenes se ejecutan durante la compilación. 


Compilación de un ejecutable (modular) 


En un proyecto, lo natural es dividir el código fuente en módulos que realizan ope- 
raciones concretas y bien definidas. En el ejemplo, podemos considerar un módulo la 
declaración y definición de la clase Square. Esta extracción se puede realizar de muchas 
maneras. Lo habitual es crear un fichero de cabecera .h con la declaración de la clase y 
un fichero .cpp con la definición: 


Listado 2.3: Archivo de cabecera Square.h 


class Square 4 
private: 
int side; 


Square(int side length); 
int getArea() const; 


1 

2 

3 

4 

5 public: 
6 

7 

38 y; 


Listado 2.4: Implementación (Square. cpp) 


include "Square.h" 


Square: :Square (int side length) : side _(side length) 
1) 


int 
Square: :getArea() const 
t 

return side _*side_; 


J 


O000X0UAUNEA 


mn 
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De esta forma, el archivo main.cpp quedaría como sigue: 


ttinclude <iostream> 
ttinclude "Square.h" 


using namespace std; 


int main () £ 
Square square(5); 
cout << "Area: " << square.getArea() << endl; 
return 0; 


) 


Para construir el programa, se debe primero construir el código objeto del módulo 
y añadirlo a la compilación de la función principal main. Suponiendo que el archivo de 
cabecera se encuentra en un directorio llamado headers, la compilación puede realizarse 
de la siguiente manera: 


$ g++ -Iheaders -c Square.cpp 
$ g++ -Iheaders -c main.cpp 
$ g++ Square.o main.o -o main 


También se puede realizar todos los pasos al mismo tiempo: 


$ g++ -Iheaders Square.cpp main.cpp -o main 


Con la opción -I, que puede aparecer tantas veces como sea necesario, se puede añadir 
rutas donde se buscarán las cabeceras. Nótese que, por ejemplo, en main. cpp se incluyen 
las cabeceras usando los símbolos <> y . Se recomienda utilizar los primeros para el caso 
en que las cabeceras forman parte de una API pública (si existe) y deban ser utilizadas 
por otros programas. Por su parte, las comillas se suelen utilizar para cabeceras internas 
al proyecto. Las rutas por defecto son el directorio actual . para las cabeceras incluidas 
con y para el resto el directorio del sistema (normalmente, /usr/include). 





Como norma general, una buena costumbre es generar todos los archivos de código 
objeto de un módulo y añadirlos a la compilación con el programa principal. 











Compilación de una biblioteca estática 


Para este ejemplo se supone que se pretende construir una biblioteca con la que se 
pueda enlazar estáticamente y que contiene una jerarquía de clases correspondientes a 3 
tipos de figuras (Figure): Square, Triangle y Circle. Cada figura está implementada como 
un módulo (cabecera + implementación): 
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Listado 2.6: Figure.h 


*tifndef FIGURE_H 
ffdefine FIGURE_H 


class Figure 4 
public: 

virtual float getArea() const = 0; 
y; 


0O0J=]O0UuUAUNEA 


*Hendif 


Listado 2.7: Square.h 


*tinclude <Figure.h> 


1 

2 

3 class Square : public Figure ( 
4 private: 

5 float side; 
6 

7 

8 

9 


public: 
Square(float side length); 
float getArea() const; 
10 y; 


Listado 2.8: Square. cpp 


1 *include "Square.h" 

2 

3 Square: :Square (float side) : side (side) f ) 

4 float Square::getArea() const [£ return side_x*side_; ) 


Listado 2.9: Triangle.h 


*tinclude <Figure.h> 


1 

2 

3 class Triangle : public Figure £ 
4 private: 

5 float base_; 

6 float height_; 
y 

8 

9 

0 

1 


public: 
Triangle(float base_, float height_); 
float getArea() const; 
y; 


Listado 2.10: Triangle.cpp 


1 *include "Triangle.h" 

2 

3 Triangle::Triangle (float base, float height) : base (base), height_(height) ( ) 
4 float Triangle::getArea() const ( return (base_*height_)/2; ) 
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Listado 2.11: Circle.h 


1 ftinclude <Figure.h> 
2 
3 class Square : public Figure f 
4 private: 
float side; 





Square(float side_length); 


5 
6 
7 public: 
8 
9 float getArea() const; 


10 ); 
Listado 2.12: Circle.cpp 


1 *Hinclude <cmath> 

2 *tinclude "Circle.h" 

3 

4 Circle::Circle(float radious) : radious_(radious) [ ) 

5 float Circle::getArea() const [ return radious_x*(M_PIx*M_PI); ) 


Para generar la biblioteca estática llamada figures, es necesario el uso de la herra- 
mienta GNU ar: 


$ g++ -Iheaders -c Square.cpp 

$ g++ -Iheaders -c Triangle.cpp 

$ g++ -Iheaders -c Circle.cpp 

$ ar rs libfigures.a Square.o Triangle.o Circle.o 


ar es un programa que permite, entre otra mucha funcionalidad, empaquetar los archi- 
vos de código objeto y generar un índice para crear un biblioteca. Este índice se incluye 
en el mismo archivo generado y mejora el proceso de enlazado y carga de la biblioteca. 


A continuación, se muestra el programa principal que hace uso de la biblioteca: 


INSPIRE) 


*tinclude <iostream> 


1 

2 

3 Hftinclude <Square.h> 
4 *tinclude <Triangle.h> 
5 *tinclude <Circle.h> 
6 

7 

8 

9 


using namespace std; 


int main () £ 
10 Square square(5); 
11 Triangle triangle(5,10); 
12 Circle circle(10); 
13 cout << "Square area: " << square.getArea() << endl; 
14 cout << "Triangle area: " << triangle.getArea() << endl; 
15 cout << "Circle area: " << circle.getArea() << endl; 
16 return 0; 


La generación del ejecutable se realizaría de la siguiente manera: 


$ g++ main.cpp -L. -lfigures -Iheaders -o main 
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Las opciones de enlazado se especifican con -L y -1. La primera permite añadir un 
directorio donde se buscarán las bibliotecas. La segunda especifica el nombre de la bi- 
blioteca con la que debe enlazarse. 





La ruta por defecto en la que se busca las bibliotecas instaladas en el sistema depende 
uy de la distribución GNU/Linux que se utilice. Normalmente, se encuentran en /lib y 
/usr/lib 











Compilación de una biblioteca dinámica 


La generación de una biblioteca dinámica con GCC es muy similar a la de una estática. 
Sin embargo, el código objeto debe generarse de forma que pueda ser cargado en tiempo 
de ejecución. Para ello, se debe utilizar la opción -fPIC durante la generación de los 
archivos .o. Utilizando el mismo código fuente de la biblioteca figures, la compilación 
se realizaría como sigue: 


$ g++ -Iheaders -fPIC -c Square.cpp 

$ g++ -Iheaders -fPIC -c Triangle.cpp 

$ g++ -Iheaders -fPIC -c Circle.cpp 

$ g++ -o libfigures.so -shared Square.o Triangle.o Circle.o 


Como se puede ver, se utiliza GCC directamente para generar la biblioteca dinámica. 
La compilación y enlazado con el programa principal se realiza de la misma forma que 
en el caso del enlazado estático. Sin embargo, la ejecución del programa principal es 
diferente. Al tratarse de código objeto que se cargará en tiempo de ejecución, existen una 
serie de rutas predefinadas donde se buscarán las bibliotecas. Por defecto, son las mismas 
que para el proceso de enlazado. 


También es posible añadir rutas modificando la variable LD_LIBRARY_PATH: 


$ LD_LIBRARY_PATH=. ./main 


2.2.5. Otras herramientas 


La gran mayoría de las herramientas utilizadas hasta el momento forman parte de la 
distribución GNU Binutils! que se proporcionan en la mayoría de los sistemas GNU/Linux. 
Existen otras herramientas que se ofrecen en este misma distribución y que pueden ser de 
utilidad a lo largo del proceso de desarrollo: 


= c++filt: el proceso de mangling es el que se realiza cuando se traduce el nombre 
de las funciones y métodos a bajo nivel. Este mecanismo es útil para realizar la 
sobreescritura de métodos en C++. c++fi1t es un programa que realiza la operación 
inversa demangling. Es útil para depurar problemas en el proceso de enlazado. 


= objdump: proporciona información avanzada sobre los archivos objetos: símbolos 
definidos, tamaños, bibliotecas enlazadas dinámicamente, etc. Proporciona una vi- 
sión detallada y bien organizada por secciones. 


= readelf: similar a objdump pero específico para los archivos objeto para plataformas 
compatibles con el formato binario Executable and Linkable Format (ELP). 





IMás información en http: //www.gnu.org/software/binutils/ 
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= nm: herramienta para obtener los símbolos definidos y utilizados en los archivos 
objetos. Muy útil ya que permite listar símbolos definidos en diferentes partes y de 
distinto tipo (sección de datos, sección de código, símbolos de depuración, etc.) 


= ldd: utilidad que permite mostrar las dependencias de un binario con bibliotecas 
externas. 


2.2.6. Depurando con GDB 


Los programas tienen fallos y los programadores cometen errores. Los compiladores 
ayudan a la hora de detectar errores léxicos, sintácticos y semánticos del lenguaje de 
entrada. Sin embargo, el compilador no puede deducir (por lo menos hasta hoy) la lógica 
que encierra el programa, su significado final o su propósito. Estos errores se conocen 
como errores lógicos. 


Los depuradores son programas que facilitan la labor de detección de errores lógicos. 
Con un depurador, el programador puede probar una ejecución paso por paso, examinar/- 
modificar el contenido de las variables en un cierto momento, etc. En general, se pueden 
realizar las tareas necesarias para conseguir reproducir y localizar un error difícil de de- 
tectar a simple vista. Muchos entornos de desarrollo como Eclipse, .NET o Java Beans 
incorporan un depurador para los lenguajes soportados. Sin duda alguna, se trata de una 
herramienta esencial en cualquier proceso de desarrollo software. 


En esta sección se muestra el uso básico de GNU 
Debugger (GDB) , un depurador libre para sistemas 
GNU/Linux que soporta diferentes lenguajes de progra- 
mación, entre ellos C++. 


Compilar para depurar 





Figura 2.5: GDB es uno de los depu- GDB necesita información extra que, por defecto, 

radores más utilizados. GCC no proporciona para poder realizar las tareas de de- 
puración. Para ello, el código fuente debe ser compilado 
con la opción -ggdb. Todo el código objeto debe ser com- 
pilado con esta opción de compilación, por ejemplo: 


$ g++ -Iheaders -ggdb -c module.cpp 
$ g++ -Iheaders -ggdb module.o main.cpp -o main 





' Para depurar no se debe hacer uso de las optimizaciones. Éstas pueden generar có- 
digo que nada tenga que ver con el original. 
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Arrancando una sesión GDB 


Como ejemplo, se verá el siguiente fragmento de código: 


Listado 2.14: main.cpp 


Htinclude <iostream> 
using namespace std; 


class Test ( 
int _value; 
public: 
void setValue(int a) £ _value = a; y 
9 int getValue() [ return _value; $ 
10 >; 


0 3O0UAUNA 


12 float functionB(string strl1, Testx* t) 4 

13 cout << "Function B: " << strl << ", " << t->getValue() << endl; 
14 return 3.14; 

15 ) 


17 int functionA(int a) £ 

18 cout << "Function A: " << a << endl; 

19 Testx test = NULL; /x*x* ouch! x*x*/ 

20 test->setValue(15); 

21 cout << "Return B: " << functionB("Hi", test) << endl; 
22 return 5; 

23 ) 


25 int main() £ 
26 cout << "Main start" << endl; 


27 cout << "Return A: " << functionA(24) << endl; 
28 return 0; 
29 ) 


La orden para generar el binario con símbolos de depuración sería: 


$ g++ -ggdb main.cpp -o main 


Si se ejecuta el código se obtienes la siguiente salida: 


$ ./main 

Main start 
Function A: 24 
Segmentation fault 


Una violación de segmento (segmentation fault) es uno de los errores lógicos típicos 
de los lenguajes como C++. El problema es que se está accediendo a una zona de la me- 
moria que no ha sido reservada por el programa de forma explícita (por ejemplo, usando el 
operador new), por lo que el sistema operativo interviene denegando ese acceso indebido. 


A continuación, se muestra cómo iniciar una sesión de depuración con GDB para 
encontrar el origen del problema: 
$ gdb main 


Reading symbols from ./main done. 
(gdb) 
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Como se puede ver, GDB ha cargado el programa, junto con los símbolos de depu- 
ración necesarios, y ahora se ha abierto una línea de órdenes donde el usuario puede 
especificar sus acciones. 





Con los programas que fallan en tiempo de ejecución se puede generar un archivo de 
core, es decir, un fichero que contiene un volcado de la memoria en el momento en 

uy que ocurrió el fallo. Este archivo puede ser cargado en una sesión de GDB para ser 
examinado usando la opción -c. 











Examinando el contenido 


Para comenzar la ejecución del programa se puede utilizar la orden start: 


(gdb) start 
Temporary breakpoint 1 at 0x400d31: file main.cpp, line 26. 
Starting program: main 


Temporary breakpoint 1, main () at main.cpp:26 
26 cout << "Main start" << endl; 
(gdb) 





uy Todas las órdenes de GDB pueden escribirse utilizando su abreviatura. Ej: run = rr. 











De esta forma, se ha comenzado la ejecución del programa y se ha detenido en la 
primera instrucción de la función main(). Para reiniciar la ejecución basta con volver a 
ejecutar start. 


Para ver más en detalle sobre el código fuente se puede utilizar la orden list o sím- 
plemente 1: 


(gdb) list 

21 cout << "Return B: " << functionB("Hi", test) << endl; 
22 return 5; 

23 

24 

25 int main() £ 

26 cout << "Main start" << endl; 

27 cout << "Return A: " << functionA(24) << endl; 
28 return 0; 

29 ) 

(gdb) 


Como el resto de órdenes, list acepta parámetros que permiten ajustar su comporta- 
miento. 


Las órdenes que permiten realizar una ejecución controlada son las siguientes: 
= step (s): ejecuta la instrucción actual y salta a la inmediatamente siguiente sin man- 


tener el nivel de la ejecución (stack frame), es decir, entra en la definición de la 
función (si la hubiere). 


stepi se comporta igual que step pero a nivel de instrucciones máquina. 


2.2. Compilación, enlazado y depuración [43] 





= next (n): ejecuta la instrucción actual y salta a la siguiente manteniendo el stack 
frame, es decir, la definición de la función se toma como una instrucción atómica. 


nexti se comporta igual que next pero si la instrucción es una llamada a función se 
espera a que termine. 


A continuación se va a utilizar step para avanzar en la ejecución del programa. Nótese 
que para repetir la ejecución de step basta con introducir una orden vacía. En este caso, 
GDB vuelve a ejecutar la última orden. 


(gdb) s 
Main start 
27 cout << "Return A: " << functionA(24) << endl; 


(gdb) 
functionA (a=24) at main.cpp:18 
18 cout << "Function A: " << a << endl; 


(gdb) 


En este punto se puede hacer uso de las órdenes para mostrar el contenido del pará- 
metro a de la función functionA(): 


(gdb) print a 

$1 = 24 

(gdb) print úa 

$2 = (int *) Ox7fffffffelbc 


Con print y el modificador € se puede obtener el contenido y la dirección de memoria 
de la variable, respectivamente. Con display se puede configurar GDB para que muestre 
su contenido en cada paso de ejecución. 


También es posible cambiar el valor de la variable a: 


gdb) set variable a=8080 

gdb) print a 

3 = 8080 

gdb) step 

unction A: 8080 

9 Test* test = NULL; /x*x* ouch! x*x*/ 
gdb) 


La ejecución está detenida en la línea 19 donde un comentario nos avisa del error. 
Se está creando un puntero con el valor NULL. Posteriormente, se invoca un método so- 
bre un objeto que no está convenientemente inicializado, lo que provoca la violación de 
segmento: 


(gdb) next 
20 test->setValue(15); 
(gdb) 


Program received signal SIGSEGV, Segmentation fault. 
0x0000000000400df2 in Test::setValue (this=0x0, a=15) at main.cpp:8 
8 void setValue(int a) £ —value = a; y 
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Para arreglar este fallo el basta con construir convenientemente el objeto: 


int functionA(int a) £ 
cout << "Function A: " << a << endl; 
Testx* test = new Test(); 
test->setValue(15); 
cout << "Return B: " << functionB("Hi", test) << endl; 
return 5; 


Breakpoints 


La ejecución paso a paso es una herramienta útil para una depuración de grano fino. 
Sin embargo, si el programa realiza grandes iteraciones en bucles o es demasiado grande, 
puede ser un poco incómodo (o inviable). Si se tiene la sospecha sobre el lugar donde está 
el problema se pueden utilizar puntos de ruptura o breakpoints que permite detener el 
flujo de ejecución del programa en un punto determinado por el usuario y, así, dar tiempo 
para examinar cuál es el estado de ciertas variables. 


Con el ejemplo ya arreglado, se configura un breakpoint en la función functionB() y 
otro en la línea 28 con la orden break. A continuación, se ejecuta el programa hasta que 
se alcance el breakpoint con la orden run (r): 


(gdb) break functionB 

Breakpoint 1 at 0x400c15: file main.cpp, line 13. 
(gdb) break main.cpp:28 

Breakpoint 2 at 0x400ddb: file main.cpp, line 28. 
(gdb) run 

Starting program: main 

Main start 

Function A: 24 


Breakpoint 1, functionB (strl=..., t=0x602010) at gdb-fix.cpp:13 
13 cout << "Function B: " << strl << ", " << t->getValue() << endl; 
(gdb) 





uy ¡No hace falta escribir todo!. Utiliza TAB para completar los argumentos de una orden. 











Con la orden continue (c) la ejecución avanza hasta el siguiente punto de ruptura (o 
fin del programa): 


(gdb) continue 
Continuing. 
Function B: Hi, 15 
Return B: 3.14 
Return A: 5 


Breakpoint 2, main () at gdb-fix.cpp:28 
28 return 0; 
(gdb) 


Los breakpoint pueden habilitarse, inhabilitarse y/o eliminarse en tiempo de ejecu- 
ción. Además, GDB ofrece un par de estructuras similares útiles para otras situaciones: 
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= Watchpoints: la ejecución se detiene cuando una determinada expresión cambia. 


= Catchpoints: la ejecución se detiene cuando se produce un evento, como una ex- 
cepción o la carga de una librería dinámica. 


Stack y frames 


En muchas ocasiones, los errores vienen debidos a que las llamadas a funciones no 
se realizan con los parámetros adecuados. Es común pasar punteros no inicializados o 
valores incorrectos a una función/método y, por tanto, obtener un error lógico. 


Para gestionar las llamadas a funciones y procedimientos, en C/C++ se utiliza la pila 
(stack). En la pila se almacenan frames, estructuras de datos que registran las variables 
creadas dentro de una función así como otra información de contexto. GDB permite ma- 
nipular la pila y los frames de forma que sea posible identificar un uso indebido de las 
funciones. 


Con la ejecución parada en functionB(), se puede mostrar el contenido de la pila con 
la orden backtrace (bt): 


(gdb) backtrace 

*0 functionB (strl=..., t=0x602010) at main.cpp:13 

*1 0x0000000000400d07 in functionA (a=24) at main.cpp:21 
2 0x0000000000400db3 in main () at main.cpp:27 

(gdb) 


Con up y down se puede navegar por los frames de la pila, y con frame se puede selec- 
cionar uno en concreto: 


(gdb) up 

1 0x0000000000400d07 in functionA (a=24) at gdb-fix.cpp:21 

21 cout << "Return B: " << functionB("Hi", test) << endl; 

(gdb) 

2 0x0000000000400db3 in main () at gdb-fix.cpp:27 

27 cout << "Return A: " << functionA(24) << endl; 

(gdb) frame O 

0 functionB (strl=..., t=0x602010) at gdb-fix.cpp:13 

13 cout << "Function B: " << strl << ", " << t->getValue() << endl; 


(gdb) 


Una vez seleccionado un frame, se puede obte- Invocar funciones 
ner toda la información del mismo, además de mo- = : 
; h La orden cal1 se puede utilizar para in- 
dificar las variables y argumentos: vocar funciones y métodos. 


(gdb) print x*t 

$1 = (_value = 15) 

(gdb) call t->setValue(1000) 
(gdb) print x*t 

$2 = (_value = 1000) 

(gdb) 


Entornos gráficos para GDB 


El aprendizaje de GDB no es sencillo. La interfaz de línea de órdenes es muy potente 
pero puede ser difícil de asimilar, sobre todo en los primeros pasos del aprendizaje de la 
herramienta. Por ello, existen diferentes versiones gráficas que, en definitiva, hacen más 
accesible el uso de GDB: 
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= GDB TUI: normalmente, la distribución de GDB incorpora una interfaz basada en 
modo texto accesible pulsando (ctrt)+(x) y, a continuación, (a). 


= ddd y xxgdb: las librerías gráficas utilizadas son algo anticuadas, pero facilitan el 
uso de GDB. 


= gdb-mode: modo de Emacs para GDB. Dentro del modo se puede activar la opción 
M-x many-windows para obtener buffers con toda la información disponible. 


= kdbg: más atractivo gráficamente (para escritorios KDE). 


2.2.7. Construcción automática con GNU Make 


En los ejemplos propuestos en la sección 2.2.2 se puede apreciar que el proceso de 
compilación no es trivial y que necesita de varios pasos para llevarse a cabo. A medida 
que el proyecto crece es deseable que el proceso de construcción de la aplicación sea lo 
más automático y fiable posible. Esto evitará muchos errores de compilación a lo largo 
del proceso de desarrollo. 


GNU Make es una herramienta genérica para especificar un proceso de construcción. 
Simplemente especificando las dependencias entre archivos y las acciones que hay que 
llevar a cabo cuando dichas dependencias se cumplen, es posible definir un proceso de 
construcción. Make es una herramienta genérica, por lo que puede ser utilizada para ge- 
nerar cualquier tipo de archivo desde sus dependencias. Por ejemplo, podemos crear ar- 
chivos ejecutables a partir de ficheros de C++, pero también una imagen PNG a partir de 
una imagen vectorial SVG, obtener la gráfica en JPG de una hoja de cálculo de LibreOf- 
fice, etc. 


Sin duda, el uso más extendido es la automatización del proceso de construcción de 
aplicaciones. Además, Make ofrece la característica de que sólo reconstruye los archivos 
que han sido modificados, por lo que no es necesario recompilar todo el proyecto cada 
vez que se realiza algún cambio. Y tiene numerosas reglas built-in para diferentes pro- 
gramas (GCC, Flex, Bison, FORTRAN, etc.) que facilitan enormemente la construcción 
automática de programas. 


Estructura 


Los archivos de Make se suelen almacenar en archivos llamados Makefile. La estruc- 
tura de estos archivos puede verse en el siguiente listado de código: 


++ Variable definitions 
VAR1='/home/user' 
export VAR2='yes' 


$ Rules 
targetl: dependencyl dependency2 ... 
actionl 
action2 
dependency1: dependency3 
action3 
action4 


GNU Make toma como entrada automáticamente el archivo cuyo nombre sea GNUmakef 
makefile O Makefile, en ese orden de prioridad. Normalmente se utiliza Makefile pero 
puede modificarse este comportamiento usando la opción -f. 
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El principio del fichero Makefile se reserva para definiciones de variables que van a 
ser utilizadas a lo largo del mismo o por otros Makefiles (para ello puede utilizar export). 
A continuación, se definen el conjunto de reglas de construcción para cada uno de los 
archivos que se pretende generar a partir de sus dependencias. Por ejemplo, el archivo 
targetl necesita que existan dependencyl, dependency2, etc. action1 y action2 indican 
cómo se construye. La siguiente regla tiene como objetivo dependency1 e igualmente se 
especifica cómo obtenerlo a partir de dependency3. 





A Las acciones de una regla van siempre van precedidas de un carácter de tabulado. 











Existen algunos objetivos especiales como al1, install y clean que sirven como regla 
de partida inicial, para instalar el software construido y para limpiar del proyecto los 
archivos generados, respectivamente. Este tipo de objetivos son denominados objetivos 
ficticios porque no generan ningún archivo y se ejecutarán siempre que sean invocados y 
no exista ningún archivo con su nombre. 


Tomando como ejemplo la aplicación que hace uso de la biblioteca dinámica, el si- 
guiente listado muestra el Makefile que generaría tanto el programa ejecutable como la 
biblioteca estática: 


all: main 


main: main.o libfigures.a 
g++ main.o -L. -lfigures -o main 


main.o: main.cpp 
g++ -Iheaders -c main.cpp 


libfigures.a: Square.o Triangle.o Circle.o 
ar rs libfigures.a Square.o Triangle.o Circle.o 


Square.o: Square.cpp 
g++ -Iheaders -fPIC -c Square.cpp 


Triangle.o: Triangle.cpp 
g++ -Iheaders -fPIC -c Triangle.cpp 


Circle.o: Circle.cpp 
g++ -Iheaders -fPIC -c Circle.cpp 


clean: 
rm -f *.0 *.a main 


Con ello, se puede construir el proyecto utilizando make [objetivo]. Si no se propor- 
ciona objetivo se toma el primero en el archivo. De esta forma, se puede construir todo el 
proyecto, un archivo en concreto o limpiarlo completamente. Por ejemplo, para construir 
y limpiar todo el proyecto se ejecutarían las siguientes Órdenes: 


$ make 
$ make clean 


Como ejercicio, se plantean las siguientes preguntas: ¿qué opción permite ejecutar 
make sobre otro archivo que no se llame Makefile? ¿Se puede ejecutar make sobre un di- 
rectorio que no sea el directorio actual? ¿Cómo? 
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GNU Coding Standards 

En el proyecto GNU se definen los ob- Variables automáticas y reglas con patrones 
jetivos que se esperan que se incluyan 
en un Makefile de cualquier proyecto 


: ol Make se caracteriza por ofrecer gran versatili- 
software que siga estas directrices. 


dad en su lenguaje. Las variables automáticas con- 
tienen valores que dependen del contexto de la re- 
gla donde se aplican y permiten definir reglas ge- 
néricas. Por su parte, los patrones permiten generalizar las reglas utilizando el nombre los 
archivos generados y los fuentes. 


A continuación se presenta una versión mejorada del anterior Makefile haciendo uso 
de variables, variables automáticas y patrones: 


LIB_OBJECTS=Square.o Triangle.o Circle.o 
all: main 


main: main.o libfigures.a 
g++ $< -L. -lfigures -o $08 


libfigures.a: $(LIB_OBJECTS) 
ar rs $8 $ 


%.0: %.Cpp 
g++ -Iheaders -c $< 


clean: 
$(RM) x*.0 *.a main 


A continuación se explica cada elemento con más detalle: 


= Variable de usuario LIB_OBJECTS: se trata de la lista de archivos objetos que forman 
la biblioteca. Al contenido se puede acceder utilizando el operador $(). 


= Variable predefinada RM: con el valor rm -f. Se utiliza en el objetivo clean. 


= Variables automáticas $6, $<, $”: se utiliza para hacer referencia al nombre del ob- 
jetivo de la regla, al nombre de la primera dependencia y a la lista de todas las 
dependencias de la regla, respectivamente. 


= Regla con patrón: en línea 12 se define una regla genérica a través de un patrón en 
el que se define cómo generar cualquier archivo objeto .o, a partir de un archivo 
fuente .cpp. 


Como ejercicio se plantean las siguientes cuestiones: ¿qué ocurre si una vez cons- 
truido el proyecto se modifica algún fichero .cpp? ¿Y si se modifica una cabecera .h? 
¿Se podría construir una regla con patrón genérica para construir la biblioteca estática? 
¿Cómo lo harías? 


Reglas implícitas 


Como se ha dicho, GNU Make es ampliamente utilizado para la construcción de pro- 
yectos software donde están implicados diferentes procesos de compilación y generación 
de código. Por ello, proporciona las llamadas reglas implícitas de forma que si el usuario 
define ciertas variables, Make puede deducir cómo construir los objetivos en base a los 
nombres de los archivos, lenguaje utilizado, etc. ¡Make es muy listo!. 
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A continuación, se transforma el ejemplo anterior utilizando las reglas implícitas: 


CC=g++ 
CXXFLAGS=-Iheaders 
LDFLAGS=-L. 
LDLIBS=-lfigures 


LIB_OBJECTS=Square.o Triangle.o Circle.o 
all: libfigures.a main 


libfigures.a: $(LIB_OBJECTS) 
S(AR) r $0 $ 


clean: 
$(RM) *+.0 x.a main 


Como se puede ver, Make puede generar automáticamente los archivos objeto .o a 
partir de la coincidencia con el nombre del fichero fuente (que es lo habitual). Por ello, 
no es necesario especificar cómo construir los archivos .o de la biblioteca, ni siquiera la 
regla para generar main ya que asume de que se trata del ejecutable (al existir un fichero 
llamado main.cpp). 


Las variables de usuario que se han definido permiten configurar los flags de compi- 
lación que se van a utilizar en las reglas explícitas. Así: 
= CC: la orden que se utilizará como compilador. En este caso, el de C++. 


= CXXFLAGS: los flags para el preprocesador y compilador de C++ (ver sección 2.2.3). 
Aquí sólo se define la opción -I, pero también es posible añadir optimizaciones y 
la opción de depuración -ggdb O -fPIC para las bibliotecas dinámicas. 


= LDFLAGS: flags para el enlazador (ver sección 2.2.3). Aquí se definen las rutas de 
búsqueda de las bibliotecas estáticas y dinámicas. 


= LDLIBS: en esta variable se especifican las opciones de enlazado. Normalmente, bas- 
ta con utilizar la opción -1 con las bibliotecas necesarias para generar el ejecutable. 





En GNU/Linux, el programa pkg-config permite conocer los flags de compilación y 
enlazado de una biblioteca determinada. 











Funciones 


GNU Make proporciona un conjunto de funciones que pueden ser de gran ayuda a 
la hora de construir los Makefiles. Muchas de las funciones están diseñadas para el tra- 
tamiento de cadenas, ya que se suelen utilizar para manipular los nombres de archivos. 
Sin embargo, existen muchas otras como para realizar ejecución condicional, bucles o 
ejecutar Órdenes de consola. En general, las funciones tienen el siguiente formato: 


$(nombre argl,arg2,arg3,...) 
Las funciones se pueden utilizar en cualquier punto del Makefile, desde las acciones 


de una regla hasta en la definición de un variable. En el siguiente listado se muestra el uso 
de algunas de estas funciones: 
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CC=g++ 


ifeq ($(DEBUG),yes) 
CXXFLAGS=-Iheader -Wall -ggdb 
else 
CXXFLAGS=-Theader -02 
endif 


LDFLAGS=-L. 
LDLIBS=-1figures 


LIB_OBJECTS=Square.o Triangle.o Circle.o 


all: libfigures.a main 
$(info AU done!) 


libfigures.a: $(LIB_OBJECTS) 
$(AR) r $e $% 
$(warning Compiled objects from $(foreach 0BJ, 
$(LIB_OBJECTS), 
$(patsubst %.o, %.cpp,$(0BJ)))) 


clean: 
$(RM) *.0 x*.a main 
$(shell find -name '*-* -delete) 


Las funciones que se han utilizado se definen a continuación: 


= Funciones condicionales: funciones como ifeq O ifneg permiten realizar una eje- 
cución condicional. En este caso, si existe una variable de entorno llamada DEBUG 
con el valor yes, los flags de compilación se configuran en consecuencia. 


Para definir la variable DEBUG, es necesario ejecutar make como sigue: 
$ DEBUG=yes make 


= Funciones de bucles: foreach permite aplicar una función a cada valor de una lista. 
Este tipo de funciones devuelven una lista con el resultado. 


= Funciones de tratamiento de texto: por ejemplo, patsubst toma como primer pa- 
rámetro un patrón que se comprobará por cada 08J. Si hay matching, será sustituido 
por el patrón definido como segundo parámetro. En definitiva, cambia la extensión 
.0 por .cpp. 

= Funciones de log: info, warning, error, etc. permiten mostrar texto a diferente nivel 
de severidad. 


= Funciones de consola: shell es la función que permite ejecutar órdenes en un 
terminal. La salida es útil utilizarla como entrada a una variable. 


Más información 


GNU Make es una herramienta que está en continuo crecimiento y esta sección sólo 
ha sido una pequeña presentación de sus posibilidades. Para obtener más información 
sobre las funciones disponibles, otras variables automáticas y objetivos predefinidos se 
recomiendo utilizar el manual en línea de Make?, el cual siempre se encuentra actualizado. 





2http://www.gnu.org/software/make/manual/make.html 


2.3. Gestión de proyectos y documentación [51] 





2.3. Gestión de proyectos y documentación 


Los proyectos software pueden ser realizados por varios equipos de personas, con 
formación y conocimientos diferentes, que deben colaborar entre sí. Además, una com- 
ponente importante del proyecto es la documentación que se genera durante el transcurso 
del mismo, es decir, cualquier documento escrito o gráfico que permita entender mejor 
los componentes del mismo y, por ello, asegure una mayor mantenibilidad para el futuro 
(manuales, diagramas, especificaciones, etc.). 


La gestión del proyecto es un proceso transversal al resto de procesos y tareas y se 
ocupa de la planificación y asignación de los recursos de los que se disponen. Se trata 
de un proceso dinámico, ya que debe adaptarse a los diferentes cambios e imprevistos 
que puedan surgir durante el desarrollo. Para detectar estos cambios a tiempo, dentro 
de la gestión del proyecto se realizan tareas de seguimiento que consisten en registrar y 
notificar errores y retrasos en las diferentes fases y entregas. 


Existen muchas herramientas que permiten crear entornos colaborativos que facilitan 
el trabajo tanto a desarrolladores como a los jefes de proyecto, los cuales están más centra- 
dos en las tareas de gestión. En esta sección se presentan algunos entornos colaborativos 
actuales, así como soluciones específicas para un proceso concreto. 


2.3.1. Sistemas de control de versiones 


El resultado más importante de un proyecto software son los archivos de distinto tipo 
que se generan; desde el código fuente, hasta los diseños, bocetos y documentación del 
mismo. Desde el punto de vista técnico, se trata de gestionar una cantidad importante de 
archivos que son modificados a lo largo del tiempo por diferentes personas. Además, es 
posible que para un conjunto de archivos sea necesario volver a una versión anterior o 
mantener diferentes versiones del proyecto al mismo tiempo. 


Por ejemplo, un fallo de diseño puede tener como consecuencia que se genere un 
código que no es escalable y difícil de mantener. Si es posible volver a un estado original 
conocido (por ejemplo, antes de tomarse la decisión de diseño), el tiempo invertido en 
revertir los cambios es menor. 


Por otro lado, sería interesante tener la posibilidad de realizar desarrollos en paralelo 
de forma que pueda existir una versión «estable» de todo el proyecto y otra más «expe- 
rimental» del mismo donde se probaran diferentes algoritmos y diseños. De esta forma, 
probar el impacto que tendría nuevas implementaciones sobre el proyecto no afectaría a 
una versión «oficial», lo cual proporciona una gran flexibilidad. También es común que 
se desee añadir una nueva funcionalidad y ésta se realiza en paralelo junto con otros de- 
sarrollos. 


Los sistemas de control de versiones o Version Control System (VCS) permiten ges- 
tionar los archivos de un proyecto (y sus versiones) y que sus integrantes puedan acceder 
remotamente a ellos para descargarlos, modificarlos y publicar los cambios. También se 
encargan de detectar posibles conflictos cuando varios usuarios modifican los mismos 
archivos y de proporcionar un sistema básico de registro de cambios. 





Como norma general, al VCS debe subirse el archivo fuente y nunca el archivo ge- 
uy nerado. No se deben subir archivos a los que sea difícil seguir la pista de sus modifi- 
caciones (por ejemplo, archivos ejecutables). 
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Sistemas centralizados vs. distribuidos 

Existen diferentes criterios para clasificar los diferentes VCS existentes. Uno de los 
que más influye tanto en la organización y uso del repositorio es si se trata de VCS cen- 
tralizado o distribuido. En la figura 2.6 se muestra un esquema de ambas filosofías. 


Centralizado ; Distribuido 






Figura 2.6: Esquema centralizado vs. distribuido de VCS 


Los VCS centralizados como CVS o Subversion se basan en que existe un nodo servi- 
dor con el que todos los clientes conectan para obtener los archivos, subir modificaciones, 
etc. La principal ventaja de este esquema reside en su sencillez: las diferentes versiones 
del proyecto están únicamente en el servidor central, por lo que los posibles conflictos 
entre las modificaciones de los clientes pueden detectarse y gestionarse más fácilmente. 
Sin embargo, el servidor es un único punto de fallo y en caso de caída, los clientes quedan 
aislados. 


Por su parte, en los VCS distribuidos como Mercurial o Git, cada cliente tiene un 
repositorio local al nodo en el que se suben los diferentes cambios. Los cambios pueden 
agruparse en changesets, lo que permite una gestión más ordenada. Los clientes actúan 
de servidores para el resto de los componentes del sistema, es decir, un cliente puede 
descargarse una versión concreta de otro cliente. 


Esta arquitectura es tolerante a fallos y permite a los clientes realizar cambios sin 
necesidad de conexión. Posteriormente, pueden sincronizarse con el resto. Aún así, un 
VCS distribuido puede utilizarse como uno centralizado si se fija un nodo como servidor, 
pero se perderían algunas posibilidades que este esquema ofrece. 


Subversion 


Subversion (SVN) es uno de los VCS centralizado más utilizado, probablemente, de- 
bido a su sencillez en el uso. Básicamente, los clientes tienen accesible en un servidor 
todo el repositorio y es ahí donde se envían los cambios. 


Para crear un repositorio, en el servidor se puede ejecutar la siguiente orden: 


$ svnadmin create /var/repo/myproject 


En /var/repo/myproject se creará un árbol de directorios que contendrá toda la infor- 
mación necesaria para mantener la información de SVN. Una vez hecho esto es necesario 
hacer accesible este directorio a los clientes. En lo que sigue, se supone que los usuarios 
tienen acceso a la máquina a través de una cuenta SSH, aunque se pueden utilizar otros 
métodos de acceso. Es recomendable que el acceso al repositorio esté controlado. HTTPS 
o SSH son buenas opciones de métodos de acceso. 


Inicialmente, los clientes pueden descargarse el repositorio por primera vez utilizando 
la orden checkout: 
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$ svn checkout svn+ssh://userlemyserver: /var/repo/myproject 
Checked out revision X. 


Esto ha creado un directorio myproject con el contenido del repositorio. Una vez des- 
cargado, se pueden realizar todos los cambios que se deseen y, posteriormente, subirlos al 
repositorio. Por ejemplo, añadir archivos y/o directorios: 


$ mkdir doc 

$ echo "This is a new file" > doc/new_file 
$ echo "Other file" > other_file 

$ svn add doc other_file 


A doc 
A doc/new_file 
A other_file 


La operación add indica qué archivos y directorios han sido seleccionados para ser 
añadidos al repositorio (marcados con A). Esta operación no sube efectivamente los archi- 
vos al servidor. Para subir cualquier cambio se debe hacer un commit: 


$ svn commit 


A coninuación, se lanza un editor de texto? para que se especifique un mensaje que 
describa los cambios realizados. Además, también incluye un resumen de todas las ope- 
raciones que se van a llevar a cabo en el commit (en este caso, sólo se añaden elementos). 
Una vez terminada la edición, se salva y se sale del editor y la carga comenzará. 


Cada commit aumenta en 1 el número de revisión. Ese número será el que podremos 
utilizar para volver a versiones anteriores del proyecto utilizando: 


$ svn update -r REVISION 


Si no se especifica la opción -r, la operación update trae la última revisión (head). 


En caso de que otro usuario haya modificado los mismos archivos y lo haya subido 
antes al repositorio central, al hacerse el commit se detectará un conflicto. Como ejemplo, 
supóngase que el cliente user2 ejecuta lo siguiente: 


$ svn checkout svn+ssh://user2Gmyserver: /var/repo/myproject 
$ echo "I change this file" > other_file 

$ svn commit 

Committed revision X+1. 


Y que el cliente user1, que está en la versión X, ejecuta lo siguiente: 


$ echo "I change the content" > doc/new_file 
$ svn remove other_file 

D other_file 

$ svn commit 

svn: Commit failed (details follow): 

svn: File 'other_file' is out of date 


Para resolver el conflicto, el cliente user1 debe actualizar su versión: 


$ svn update 
C other_file 
At revision X+1. 





3El configurado en la variable de entorno EDITOR. 
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La marca C indica que other_file queda en conflicto y que debe resolverse manual- 
mente. Para resolverlo, se debe editar el archivo donde Subversion marca las diferencias 
con los símbolos '<' y '>". 


También es posible tomar como solución el revertir los cambios realizados por user1l 
y, de este modo, aceptar los de user2: 


$ svn revert other_file 
$ svn commit 
Committed revision X+2. 


Nótese que este commit sólo añade los cambios hechos en new_file, aceptando los 
cambios en other_file que hizo userz. 


Mercurial 


Como se ha visto, en los VCS centralizados como Subversion no se permite, por 
ejemplo, que los clientes hagan commits si no están conectados con el servidor central. 
Los VCS como Mercurial (HG), permiten que los clientes tengan un repositorio local, con 
su versión modificada del proyecto y la sincronización del mismo con otros servidores 
(que pueden ser también clientes). 


Para crear un repositorio Mercurial, se debe ejecutar 
lo siguiente: 


$ hg init /home/userl/myproyect 


) Al igual que ocurre con Subversion, este directorio 
debe ser accesible mediante algún mecanismo (preferl- 
blemente, que sea seguro) para que el resto de usuarios 


pueda acceder. Sin embargo, el usuario user1 puede tra- 
bajar directamente sobre ese directorio. 


> Para obtener una versión inicial, otro usuario (user2) 
M O FC U [ | d debe clonar el repositorio. Basta con ejecutar lo siguiente: 


Figura 2.7: Logotipo del proyecto $ hg clone ssh: //user2Ghost//home/user1/myproyect 
Mercurial. 
A partir de este instante, user2 tiene una versión ini- 
cial del proyecto extraída a partir de la del usuario userl. 
De forma muy similar a Subversion, con la orden add se 
pueden añadir archivos y directorios. 


Mientras que en el modelo de Subversion, los clientes 
hacen commit y update para subir cambios y obtener la última versión, respectivamente; 
en Mercurial es algo más complejo, ya que existe un repositorio local. Como se muestra 
en la figura 2.8, la operación commit (3) sube los cambios a un repositorio local que cada 
cliente tiene. 


Cada commit se considera un changeset, es decir, un conjunto de cambios agrupados 
por un mismo ID de revisión. Como en el caso de Subversion, en cada commit se pedirá 
una breve descripción de lo que se ha modificado. 


Una vez hecho todos commits, para llevar estos cambios a un servidor remoto se debe 
ejecutar la orden de push (4). Siguiendo con el ejemplo, el cliente user2 lo enviará por 
defecto al repositorio del que hizo la operación clone. 
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1: pull 

2: update Servidor 
3: commit 

4: push 






O Repositorio local 


1 





Cliente 


O 







Proyecto 
(archivos) 


Figura 2.8: Esquema del flujo de trabajo básico en Mercurial 


El sentido inverso, es decir, traerse los cambios del servidor remoto a la copia local, 
se realiza también en 2 pasos: pull (1) que trae los cambios del repositorio remoto al 
repositorio local; y update (2), que aplica dichos cambios del repositorio local al directorio 
de trabajo. Para hacer los dos pasos al mismo tiempo, se puede hacer lo siguiente: 


$ hg pull -u 





Para evitar conflictos con otros usuarios, una buena costumbre antes de realizar un 
YN push es conveniente obtener los posibles cambios en el servidor con pull y update. 











Para ver cómo se gestionan los conflictos en Mercurial, supóngase que user1 realiza 
lo siguiente: 


echo "A file" > a_file 
hg add a-file 
hg commit 


4A A A 


Al mismo tiempo, user2 ejecuta lo siguiente: 


echo "This is one file" > a_file 

hg add a_file 

hg commit 

hg push 

abort: push creates new remote head xxxxxx! 

(you should pull and merge or use push -f to force) 


4A A A A 


Al intentar realizar el push y entrar en conflicto, Mercurial avisa de ello deteniendo 
la carga. En este punto se puede utilizar la opción -f para forzar la operación de push, 
lo cual crearía un nuevo head. Como resultado, se crearía una nueva rama a partir de 
ese conflicto de forma que se podría seguir desarrollando omitiendo el conflicto. Si en el 
futuro se pretende unir los dos heads se utilizan las operaciones merge y resolve. 


[56] 
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hgview 


a 
hgview es una herramienta gráfica que 
permite visualizar la evolución de las 
ramas y heads de un proyecto que usa 
Mercurial. 


$ hg pull 

adding changesets 
adding manifests 
adding file changes 


La otra solución, más común, es obtener los 
cambios con pull, unificar heads (merge), resolver 
los posibles conflictos manualmente si es necesa- 
rio (resolve), hacer commit de la solución dada 
(commit) y volver a intentar la subida (push): 


added 2 changesets with 1 changes to 1 files (+1 heads) 
(run 'hg heads' to see heads, 'hg merge' to merge) 


$ hg merge 

merging a_file 

warning: conflicts during merge. 
merging a_file failed! 


O files updated, O files merged, O files removed, 1 files unresolved 


$ hg resolve -a 
$ hg commit 
$ hg push 








Para realizar cómodamente la tarea de resolver los conflictos manualmente existen 
y herramientas como meld que son invocadas automáticamente por Mercurial cuando 
se encuentran conflictos de este tipo. 








Git 





Diseñado y desarrollado por Linus Torvalds para el 
proyecto del kernel Linux, Git es un VCS distribuido que 


o cada vez es más utilizado por la comunidad de desarro- 
1 lladores, sobre todo en el ámbito del Software Libre. En 
términos generales, tiene una estructura similar a Mercu- 
rial: independencia entre repositorio remotos y locales, 


Figura 2.9: Logotipo del proyecto gestión local de cambios, etc. 


Git. 


Sin embargo, Git es en ocasiones preferido sobre 


Mercurial por algunas de sus características propias: 


= Eficiencia y rapidez a la hora de gestionar grandes cantidades de archivos. Git no 
funciona peor conforme la historia del repositorio crece. 


= Facilita el desarrollo no lineal, es decir, el programador puede crear ramas locales 
e integrar los cambios entre diferentes ramas (tanto remotas como locales) de una 
forma simple y con muy poco coste. Git está diseñado para que los cambios puedan 
ir de rama a rama y ser revisados por diferentes usuarios. Es una herramienta muy 


potente de revisión de código. 


= Diseñado como un conjunto de pequeñas herramientas, la mayoría escritas en C, 
que pueden ser compuestas entre ellas para hacer tareas más complejas. Su estruc- 
tura general recuerda a las herramientas UNIX como sort, 1s, sed, etc. que realizan 
tareas muy específicas y concretas y, al mismo tiempo, se pueden componer unas 


con otras. 
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En general, Git proporciona más flexibilidad al usuario, permitiendo hacer tareas com- 
plejas y de grano fino (como la división de un cambio en diferentes cambios) y al mismo 
tiempo es eficiente y escalable para proyectos con gran cantidad de archivos y usuarios 
concurrentes. 


Un repositorio Git está formado, básicamente, por un conjunto de objetos commit y 
un conjunto de referencias a esos objetos llamadas heads. Un commit es un concepto 
similar a un changeset de Mercurial y se compone de las siguientes partes: 


= El conjunto de ficheros que representan al proyecto en un momento concreto. 
= Referencias a los commits padres. 
= Un nombre formado a partir del contenido (usando el algoritmo SHA1). 


Cada head apunta a un commit y tiene un nombre simbólico para poder ser referen- 
ciado. Por defecto, todos los respositorios Git tienen un head llamado master. HEAD 
(nótese todas las letras en mayúscula) es una referencia al head usado en cada instante. 
Por lo tanto, en un repositorio Gít, en un estado sin cambios, HEAD apuntará al master 
del repositorio. 


Para crear un repositorio donde sea posible que otros usuarios puedan subir cambios 
se utiliza la orden init: 


$ git init --bare /home/userl/myproyect 


La opción -bare indica a Git que se trata de un repositorio que no va a almacenar 
una copia de trabajo de usuario, sino que va a actuar como sumidero de cambios de los 
usuarios del proyecto. Este directorio deberá estar accesible para el resto de los usuarios 
utilizando algún protocolo de comunicación soportado por Git (ssh, HTTP, etc.). 


El resto de usuarios pueden obtener una copia del repositorio utilizando la siguiente 
orden: 


$ git clone ssh://user2ghost/home/userl/myproyect 


A modo de ejemplo ilustrativo, otra forma de realizar la operación clone sería la si- 
guiente: 


$ git init /home/user2/myproyect 

$ cd /home/user2/myproyect 

$ git remote add -t master origin ssh://user2Ghost/home/userl/myproyect 
$ git pull 


De esta manera, una vez creado un repositorio Gít, es posible reconfigurar en la URL 
donde se conectarán las Órdenes pull y fetch para descargar el contenido. En la figura 2.10 
se muestra un esquema general del flujo de trabajo y las órdenes asociadas. Nótese la 
utilidad de la orden remote que permite definir el repositorio remoto del que recibir y al 
que se enviarán los cambios. origin es el nombre utilizado para el respositorio remoto por 
defecto, pero se pueden añadir cuantos sean requeridos. 


En Git se introduce el espacio stage (también llamado index o cache) que actúa como 
paso intermedio entre la copia de trabajo del usuario y el repositorio local. Sólo se pueden 
enviar cambios (commits) al repositorio local si éstos están previamente en el stage. Por 
ello, todos los nuevos archivos y/o modificaciones que se realicen deben ser «añadidas» 
al stage antes. 


La siguiente secuencia de comandos añaden un archivo nuevo al repositorio local. 
Nótese que add sólo añade el archivo al stage. Hasta que no se realice commit no llegará a 
estar en el repositorio local: 
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: fetch 

: checkout 

: add 

: commit 

: commit -a 
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Figura 2.10: Esquema del flujo de trabajo básico en Git 


$ echo "Test example" > example 

$ git add example 

$ git status 

* On branch master 

* Changes to be committed: 

(use "git reset HEAD <file>...'" to unstage) 


new file: example 


$ 
$ 
Ed 
Ed 
$ git commit -m "Test example: initial version" 
[master 2f81676] Test example: initial version 


1 file changed, 1 insertion(+) 
create mode 100644 example 


$ git status 
* On branch master 
nothing to commit, working directory clean 


Nótese como la última llamada a status no muestra ningún cambio por subir al re- 
positorio local. Esto significa que la copia de trabajo del usuario está sincronizada con 
el repositorio local (todavía no se han realizado operaciones con el remoto). Se puede 


utilizar reflog para ver la historia: 


$ git reflog 


2f81676 HEADGf0): commit: Test example: initial version 


diff se utiliza para ver cambios entre commits, ramas, etc. Por ejemplo, la siguiente 
orden muestra las diferencias entre master del repositorio local y master del remoto: 


$ git diff master origin/master 
diff --git a/example b/example 
new file mode 100644 

index 0000000. .ac19bf2 

--- /dev/null 

+++ b/example 

ee -0,0 +1 ee 

+Test example 
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Existen herramientas gráficas como gitk para entender mejor estos conceptos y visua- 
lizarlos durante el proceso de desarrollo y que permiten ver todos los commits y heads en 
cada instante. 


Para modificar código y subirlo al repositorio local se sigue el mismo procedimiento: 
(1) realizar la modificación, (2) usar add para añadir el archivo cambiado, (3) hacer commit 
para subir el cambio al repositorio local. Sin embargo, como se ha dicho anteriormente, 
una buena característica de Git es la creación y gestión de ramas (branches) locales que 
permiten hacer un desarrollo en paralelo incluso a nivel local, es decir, sin subir nada al 
repositorio central. Esto es muy útil ya que, normalmente, en el ciclo de vida de desarrollo 
de un programa se debe simultanear tanto la creación de nuevas características como 
arreglos de errores cometidos. En Git, estas ramas no son más que referencias a commits, 
por lo que son muy ligeras y pueden llevarse de un sitio a otro de forma sencilla. 


Como ejemplo, la siguiente secuencia de Órdenes crea una rama local a partir del 
HEAD, modifica un archivo en esa rama y finalmente realiza un merge con master: 


$ git checkout -b "NEW-BRANCH" 
Switched to a new branch 'NEW-BRANCH” 


$ git branch 
* NEW-BRANCH 
master 


$ emacs example +4 se realizan las modificaciones 
$ git add example 

$ git commit -m "remove 'example'" 

[NEW-BRANCH 263e915] remove 'example” 

1 file changed, 1 insertion(+), 1 deletion(-) 


$ git checkout master 
Switched to branch 'master” 
$ git branch 

NEW-BRANCH 

* master 


$ git merge NEW-BRANCH 

Updating 2f81676..263e915 

Fast-forward 

example | 2 +- 

1 file changed, 1 insertion(+), 1 deletion(-) 


Nótese cómo la orden branch muestra la rama actual marcada con el símbolo +. Utili- 
zando las órdenes log y show se pueden listar los commits recientes. Estas órdenes acep- 
tan, además de identificadores de commits, ramas y rangos temporales de forma que pue- 
den obtenerse gran cantidad de información de ellos. 


Finalmente, para desplegar los cambios en el repositorio remoto sólo hay que utilizar: 


$ git push 





Git utiliza ficheros como .gitconfig y .gitignore para cargar configuraciones per- 

uy sonalizadas e ignorar ficheros a la hora de hacer los commits, respectivamente. Son 
muy útiles. Revisa la documentación de git-config y gitignore para más informa- 
ción. 
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2.3.2. Sistemas de integración continua 


Un entorno que permita y facilite la colaboración entre desarrolladores de un proyecto 
es fundamental para el éxito del mismo durante las fases de desarrollo. Sin embargo, esa 
colaboración debe estar controlada por unos criterios mínimos de calidad que permitan 
asegurar que: 


= Durante la fase de desarrollo, las características que se implementan está bajo con- 
trol. 


= Cualquier error introducido pueda detectarse lo antes posible, antes de que sea de- 
masiado tarde. 


La mejor forma que, a día de hoy, ha sido aceptada para proporcionar calidad en los 
sistemas son las pruebas. Las pruebas, desde unitarias hasta de sistema, son la última 
garantía de que el sistema hace lo que esperan las pruebas de él. Si las pruebas están 
bien diseñadas y son fieles a los requisitos del proyecto, las pruebas asegurarán un gran 
calidad. Pero, ¿cómo aseguramos que las pruebas se satisfacen continuamente durante el 
desarrollo?. ¿Cómo detectamos que se ha introducido código que hace romper casos de 
prueba?. 


Los sistemas de integración continua (CI de Continous Integration) son sistemas, nor- 
malmente distribuidos, que permiten ejecutar tareas automáticas sobre proyectos cuando 
se ha introducido un nuevo cambio, periódicamente u con cualquier otra frecuencia. Ade- 
más, permiten analizar el resultado de los test ejecutados y avisar inmediatamente en caso 
de fallo. 


Jenkins 


Sin duda, uno de los sistema CI más utilizados actualmente es Jenkins. Partiendo del 
proyecto Hudson, Jenkins es un sistema CI basado en Java, distribuido y que proporciona 
una interfaz web sencilla y amigable. En la figura 2.11 se muestra del servidor Jenkins 
del proyecto Debian. 
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Figura 2.11: http: //jenkins.debian.net. Tareas construyendo chroots 
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Algunas de las características más importantes de Jenkins son: 


= Arquitectura maestro-esclavos: Un coordinador (el nodo maestro) reparte trabajo 
a los diferentes nodos esclavos (slaves) que son los que se encargarán de ejecutar 
tareas. Para convertir a un nodo de la red en esclavo sólo hay que acceder a él 
mediante algún mecanismo soportado, como SSH. Jenkins despliega una aplicación 
Java se autoinstala y autoconfigura. 


= Plugins: existe una gran cantidad de plugins que extienden la funcionalidad básica 
de Jenkins. Los plugins son fácilmente instalables y actualizables a través de la 
interfaz web. 


= Dependencias entre trabajos: es posible especificar tareas que servirán de trigger 
(disparador) de otras tareas en nodos diferentes. 


= Ejecución paralela: dentro de un nodo, es posible ejecutar diferentes ejecuciones 
de trabajos en paralelo. El grado de paralelismo vendrá condicionado por los re- 
cursos hardware del nodo, del número de ejecutores (executors) asignado y del 


grado de independencia que tengan los propios trabajos. Ésta última característica 
es muy importante. Es el usuario quien debe asignar a un nodo tareas que puedan 
ser ejecutadas en paralelo ya que puede ser que un trabajo, por ejemplo, requiera 
la existencia de un archivo A y otro requiera que no exista, por lo que no podrían 
ejecutarse en el mismo nodo en paralelo. 


= Balanceo de carga: por defecto, el algoritmo de Jenkins para balancear la carga 
no es muy bueno a no ser que establezcamos prioridades y cantidades mínimas 
de ocupación de los nodos. Sin embargo, existe una gran variedad de plugins que 
permiten gestionar eficientemente los recursos con planificadores sofisticados. 


Para poder utilizar Jenkins como servidor CI necesitas alojarlo en un servidor con 
acceso suficiente para los participantes del proyecto. En sistemas basados en Debian, 
como Ubuntu, es fácilmente instalable y prácticamente no necesita configuración para 
comenzar a usarlo. 


Otros sistemas de Cls 


A pesar de que Jenkins es uno de los sistemas de CI más utilizado, existen alternativas 
para diferentes aplicaciones. Por ejemplo, la fuerte dependencia que tiene Jenkins con 
Java puede hacerlo poco adecuado para servidores con pocos recursos. 


Algunas de las alternativas a Jenkins son las siguientes: 


= CruiseControl: basado en Java, muy similar en características y tecnología a Jen- 
kins. Proporciona multitud de plugins y una interfaz de administración web sencilla. 


= Strider-CD: implementado en JavaScript y NodeJS, se trata de un servidor CI muy 
integrado con los servicios web tales como Github, BitBucket, etc. Además de 
ejecutar cualquier combinación genérica, parte características interesantes es que 
proporciona métodos especiales de ejecución para aplicaciones JavaScript sobre 
diferentes combinaciones de navegadores. 


= BuildBot: escrito en Python, más que un servidor de Cl es un framework de CI que 
proporciona las bases para permitir construir el servidor CI que más se adapte a las 
posibilidades. 
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2.3.3. Documentación 


Uno de los elementos más importantes que se generan en un proyecto es la documen- 
tación: cualquier elemento que permita entender mejor tanto el proyecto en su totalidad 
como sus partes, de forma que facilite el proceso de mantenimiento en el futuro. Además, 
una buena documentación hará más sencilla la reutilización de componentes. 


Existen muchos formatos de documentación que pueden servir para un proyecto soft- 
ware. Sin embargo, muchos de ellos, tales como PDF, ODT, DOC, etc., son formatos 
«binarios», cuyos cambios no son fáciles de seguir, por lo que no son aconsejables para 
utilizarlos en un VCS. Además, utilizando texto plano es más sencillo crear programas 
que automaticen la generación de documentación, de forma que se ahorre tiempo en este 
proceso. 


Por ello, aquí se describen algunas formas de crear documentación basadas en texto 
plano. Obviamente, existen muchas otras y, seguramente, sean tan válidas como las que 
se proponen aquí. 


Doxygen 


Doxygen es un sistema que permite generar la documentación utilizando analizadores 
de código que averiguan la estructura de módulos y clases, así como las funciones y los 
métodos utilizados. Además, se pueden realizar anotaciones en los comentarios del código 
que sirven para añadir información más detallada. La principal ventaja es que se vale del 
propio código fuente para generar la documentación. Además, si se añaden comentarios 
en un formato determinado, es posible ampliar la documentación generada con notas y 
aclaraciones sobre las estructuras y funciones utilizadas. 





Algunos piensan que el uso de programas como Doxygen es bueno porque «obliga» 
uy a comentar el código. Otros piensan que no es así ya que los comentarios deben 
seguir un determinado formato, dejando de ser comentarios propiamente dichos. 











El siguiente fragmento de código muestra una clase en C++ documentada con el for- 
mato de Doxygen: 


[ex 
This is a test class to show Doxygen format documentation. 
*/ 


class Test £ 
public: 
/1// The Test constructor. 
/x 
Xparam s the name of the Test. 
*/ 
Test(string Ss); 


/// Start running the test. 

[rx 
Xparam max maximum time of test delay. 
Xparam silent if true, do not provide output. 
Asa Test() 

*/ 

int run(int max, bool silent); 

$; 
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Por defecto, Doxygen genera la documentación en HTML y basta con ejecutar la 
siguiente orden en el raíz del código fuente para obtener una primera aproximación: 


$ doxygen . 


reStructuredText 


reStructuredText (RST) es un formato de texto básico que permite escribir texto plano 
añadiendo pequeñas anotaciones de formato de forma que no se pierda legibilidad. Exis- 
ten muchos traductores de RST a otros formatos como PDF (rst2pdaf) y HTML (rst2html), 
que además permiten modificar el estilo de los documentos generados. 


El formato RST es similar a la sintaxis de los sistema tipo wiki. Un ejemplo de archivo 
en RST puede ser el siguiente: 


Listado 2.22: Archivo en RST 





2 
3 
4 
5 This is an example of document in ReStructured Text (RST). You can get 
6 more info about RST format at “*RST Reference 

7 <http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html>'_. 
8 

9 Other section 

19 ==== == 





12 You can use bullet items: 
14  - ItemA 

16  - Item B 

18 And a enumerated list: 
20 1. Number 1 

22 2. Number 2 


24 Tables 


36 .. image:: gnu.png 
37 scale: 80 
38 salt: A title text 


Como se puede ver, aunque RST añade una sintaxis especial, el texto es completa- 


mente legible. Ésta es una de las ventajas de RST, el uso de etiquetas de formato que no 
«ensucian» demasiado el texto. 
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YAML 


YAML (YAML Ain't Markup Language)? es un lenguaje diseñado para serializar da- 
tos procedentes de aplicaciones en un formato que sea legible para los humanos. Estricta- 
mente, no se trata de un sistema para documentación, sin embargo, y debido a lo cómodo 
de su sintaxis, puede ser útil para exportar datos, representar configuraciones, etc. Otra de 
sus ventajas es que hay un gran número de bibliotecas en diferentes lenguajes (C++, Pyt- 
hon, Java, etc.) para tratar información YAML. Las librerías permiten automáticamente 
salvar las estructuras de datos en formato YAML y el proceso inverso: cargar estructuras 
de datos a partir del YAML. 


En el ejemplo siguiente, extraído de la documentación oficial, se muestra una factura. 
De un primer vistazo, se puede ver qué campos forman parte del tipo de dato factura 
tales como invoice, date, etc. Cada campo puede ser de distintos tipo como numérico, 
booleano o cadena de caracteres, pero también listas (como product) o referencias a otros 
objetos ya declarados (como ship-to). 


Listado 2.23: Archivo en YAML 


1 --- I<tag:clarkevans.com,2002:invoice> 
2 invoice: 34843 

3 date  : 2001-01-23 

4 bill-to: $id001 

5 given : Chris 

6 family : Dumars 

7 address: 

8 lines: | 

9 458 Walkman Dr. 

10 Suite 4292 

11 city : Royal Oak 
12 state : MI 

13 postal : 48046 

14 ship-to: *id001 

15 product: 

16 - sku : BL394D 

17 quantity 24 

18 description : Basketball 
19 price : 450.00 

20 - sku : BL4438H 
21 quantity ¿1 

22 description : Super Hoop 
23 price : 2392.00 


24 tax : 251.42 
25 total: 4443.52 
26 comments: 


27 Late afternoon is best. 
28 Backup contact is Nancy 
29 Billsmer Q 338-4338. 





4http://www.yaml .org 
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2.3.4. Forjas de desarrollo 


Hasta ahora, se han mostrado herramientas específicas que permiten crear y gestionar 
los elementos más importantes de un proyecto software: los archivos que lo forman y 
su documentación. También se han mostrado algunas alternativas para usar un sistema de 
integración continua durante el proceso de desarrollo para mantener la calidad del mismo. 
Sin embargo, existen otras como la gestión de tareas, los mecanismos de notificación 
de errores o los sistemas de comunicación con los usuarios que son de utilidad en un 
proyecto. 


Las forjas de desarrollo son sistemas colaborativos que integran no sólo herramientas 
básicas para la gestión de proyectos, como un VCS, sino que suelen proporcionar herra- 
mientas para: 


= Planificación y gestión de tareas: permite anotar qué tareas quedan por hacer y 
los plazos de entrega. También suelen permitir asignar prioridades. 


= Planificación y gestión de recursos: ayuda a controlar el grado de ocupación del 
personal de desarrollo (y otros recursos). 


= Seguimiento de fallos: también conocido como bug tracker, es esencial para llevar 
un control sobre los errores encontrados en el programa. Normalmente, permiten 
gestionar el ciclo de vida de un fallo, desde que se descubre hasta que se da por 
solucionado. 


= Foros: normalmente, las forjas de desarrollo permiten administrar varios foros de 
comunicación donde con la comunidad de usuarios del programa pueden escribir 
propuestas y notificar errores. 


Las forjas de desarrollo suelen ser accesibles vía web, de forma que sólo sea necesario 
un navegador para poder utilizar los diferentes servicios que ofrece. Dependiendo de la 
forja de desarrollo, se ofrecerán más o menos servicios. Sin embargo, los expuestos hasta 
ahora son los que se proporcionan habitualmente. Existen forjas gratuitas en Internet que 
pueden ser utilizadas para la creación de un proyecto. Algunas de ellas: 


= GNA?: es una forja de desarrollo creada por la Free Software Foundation de Francia 
que soporta, actualmente, repositorios CVS, GNU Arch y Subversion. Los nuevos 
proyectos son estudiados cuidadosamente antes de ser autorizados. 


= Launchpad(: forja gratuita para proyectos de software libre creada por Canonical 
Ltd. Se caracteriza por tener un potente sistema de bug tracking y proporcionar 
herramientas automáticas para despliegue en sistemas Debian/Ubuntu. 


= BitBucket”: forja de la empresa Atlassian que ofrece repositorios Mercurial y Git. 
Permite crear proyectos privados gratuitos pero con límite en el número de desarro- 
lladores por proyecto. 


= GitHub*: forja proporcionada por GitHub Inc. que utiliza repositorios Git. Es gra- 
tuito siempre que el proyecto sea público, es decir, pueda ser descargado y modifi- 
cado por cualquier usuario de Github sin restricción. 


= SourceForge”: probablemente, una de las forjas gratuitas más conocidas. Propie- 
dad de la empresa GeekNet Inc., soporta Subversion, Git, Mercurial, Bazaar y CVS. 





Shttp://gna.org 

https ://Taunchpad.net/ 
Thttp ://bitbucket.org 
Shttp ://github.com 
http ://sourceforge.net 
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" Google Code: la forja de desarrollo de Google que soporta Git, Mercurial y Sub- 
version. 


Redmine 


Además de los servicios gratuitos presentados, existe gran variedad de software que 
puede ser utilizado para gestionar un proyecto de forma que pueda ser instalado en un 
servidor personal y así no depender de un servicio externo. Tal es el caso de Redmine 
(véase figura 2.12) que entre las herramientas que proporciona cabe destacar las siguientes 
características: 


= Permite crear varios proyectos. También es configurable qué servicios se proporcio- 
nan en cada proyecto: gestor de tareas, tracking de fallos, sistema de documentación 
wiki, etc. 


= Integración con repositorios, es decir, el código es accesible a través de Redmine y 
se pueden gestionar tareas y errores utilizando los comentarios de los commits. 


= Gestión de usuarios que pueden utilizar el sistema y sus políticas de acceso. 


= Está construido en Ruby y existe una amplia variedad de plugins que añaden fun- 
cionalidad extra. 
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Figura 2.12: Aspecto de la herramienta de gestión de tareas de Redmine 
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David Vallejo Fernández 


bido especialmente a su potencia, eficiencia y portabilidad. En este capítulo se 

hace un recorrido por C++ desde los aspectos más básicos hasta las herramien- 
tas que soportan la POO (Programación Orientada a Objetos) y que permiten diseñar y 
desarrollar código que sea reutilizable y mantenible, como por ejemplo las plantillas y las 
excepciones. 


F lenguaje más utilizado para el desarrollo de videojuegos comerciales es C++, de- 


3.1. Utilidades básicas 


En esta sección se realiza un recorrido por los POO 
aspectos básicos de C++, haciendo especial hin- La ro prmación nta ca ES 
capié en aquellos elementos que lo diferencian de tiene como objetivo la organización efi- 
otros lenguajes de programación y que, en ocasio- caz de programas. Básicamente, cada 


nes, pueden resultar más complicados de dominar “Componente es un objeto autoconteni- 


: do que tiene una serie de operaciones y 
por aquellos programadores inexpertos en C++. o ud. 


3.1.1. Introducción a C++ 


C++ se puede considerar como el lenguaje de 

programación más importante en la actualidad. De hecho, algunas autores relevantes [13] 
consideran que si un programador tuviera que aprender un único lenguaje, éste debería 
ser C++. Aspectos como su sintaxis y su filosofía de diseño definen elementos clave de 
programación, como por ejemplo la orientación a objetos. C++ no sólo es importante por 
sus propias características, sino también porque ha sentado las bases para el desarrollo de 
futuros lenguajes de programación. Por ejemplo, Java o CH son descendientes directos de 
C++. Desde el punto de vista profesional, C++ es sumamente importante para cualquier 
programador. 
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El origen de C++ está ligado al origen de C, ya que C++ está construido sobre C. De 
hecho, C++ es un superconjunto de C y se puede entender como una versión extendida y 
mejorada del mismo que integra la filosofía de la POO y otras mejoras, como por ejem- 
plo la inclusión de un conjunto amplio de bibliotecas. Algunos autores consideran que 
C++ surgió debido a la necesidad de tratar con programas de mayor complejidad, siendo 
impulsado en gran parte por la POO. 


C++ fue diseñado por Bjarne Stroustrup! en 1979. La idea de Stroustrup fue añadir 
nuevos aspectos y mejoras a C, especialmente en relación a la POO, de manera que un 
programador de C sólo que tuviera que aprender aquellos aspectos relativos a la OO. 


En el caso particular de la industria del videojuego, 
C++ se puede considerar como el estándar de facto debi- 
do principalmente a su eficiencia y portabilidad. C++ es 
una de los pocos lenguajes que posibilitan la programa- 
ción de alto nivel y, de manera simultánea, el acceso a los 
recursos de bajo nivel de la plataforma subyacente. Por 
lo tanto, C++ es una mezcla perfecta para la programa- 
ción de sistemas y para el desarrollo de videojuegos. Una 
de las principales claves a la hora de manejarlo eficiente- 
Figura 3.1: Bjarne Stroustrup, crea- Mente en la industria del videojuego consiste en encontrar 
dor del lenguaje de programación el equilibrio adecuado entre eficiencia, fiabilidad y man- 


C++ y personaje relevante en el ám-  tenibilidad [3]. 
bito de la programación. 





3.1.2. ¡Hola Mundo! en C++ 


continuación se muestra el clásico ¡Hola Mundo! implementado en . En este 
A cont tra el cl ¡Hola Mundo! 1 tad C++. En est 
primer ejemplo, se pueden apreciar ciertas diferencias con respecto a un programa escrito 
en C. 


Listado 3.1: Hola Mundo en C++ 


/* Mi primer programa con C++. */ 


1 

2 

3 Htinclude <iostream> 
4 using namespace std; 
5 

6 

7 

8 


int main () £ 
string nombre; 
10 cout << "Por favor, introduzca su nombre... "; 
11 cin >> nombre; 


12 cout << "Hola " << nombre << "!"<< endl; 


14 return 0; 


La directiva include de la línea (3) incluye la biblioteca <iostream>, la cual soporta 
el sistema de E/S de C++. A continuación, en la (4) el programa le indica al compilador 
que utilice el espacio de nombres sfd, en el que se declara la biblioteca estándar de C++. 
Un espacio de nombres delimita una zona de declaración en la que incluir diferentes 
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elementos de un programa. Los espacios de nombres siguen la misma filosofía que los 
paquetes en Java y tienen como objetivo organizar los programas. El hecho de utilizar 
un espacio de nombres permite acceder a sus elementos y funcionalidades sin tener que 
especificar a qué espacio pertenecen. 


Dominar C++ En la línea (19) de hace uso de cout (console out- 
Un de las mayores ens de de put), la sentencia de salida por consola junto con 
es que es extremadamente potente. Sin el operador <<, redireccionando lo que queda a 
embargo, utilizarlo eficientemente es su derecha, es decir, Por favor, introduzca su nom- 
díficil y su curva de aprendizaje no es bre..., hacia la salida por consola. A continuación, 


gradual. en la siguiente línea se hace uso de cin (console 


input) junto con el operador >> para redirigir la 
entrada proporcionado por teclado a la variable nombre. Note que dicha variable es de 
tipo cadena, un tipo de datos de C++ que se define como un array de caracteres finalizado 
con el carácter null. Finalmente, en la línea se saluda al lector, utilizando además la 
sentencia endl para añadir un retorno de carro a la salida y limpiar el buffer. 


3.1.3. Tipos, declaraciones y modificadores 


En C++, los tipos de datos básicos y sus declaraciones siguen un esquema muy similar 
al de otros lenguajes de programación, como por ejemplo Java. En este caso, existen siete 
tipos de datos básicos: carácter, carácter amplio, entero, punto flotante, punto flotante de 
doble precisión, lógico o booleano y nulo. Recuerde que en C++ es necesario declarar 
una variable antes de utilizarla para que el compilador conozca el tipo de datos asociado a 
la variable. Al igual que ocurre en otros lenguajes de programación, las variables pueden 
tener un alcance global o local (por ejemplo en una función). 


En el caso particular de los tipos nulos o void, cabe destacar que éstos se utilizan para 
las funciones con tipo de retorno nulo o como tipo base para punteros a objetos de tipo 
desconocido a priori. 


C++ permite modificar los tipos char, int y double con los modificadores signed, 
unsigned long, y short, con el objetivo de incrementar la precisión en función de las 
necesidades de la aplicación. Por ejemplo, el tipo de datos double se puede usar con el 
modificador long, y no así con el resto. 


Por otra parte, C++ también posibilita el con- 
cepto de constante mediante la palabra reservada Gia es un lenguaje de propranación 
const, con el objetivo de expresar que un valor no con tipado estático, es decir, la com- 
cambia de manera directa. Por ejemplo, muchos probación de tipos se realiza en tipo de 
objetos no cambian sus valores después de iniciali- compilación y no en tiempo de ejecu- 
zarlos. Además, las constantes conducen a un códi- 10M: 
go más mantenible en comparación con los valores literales incluidos directamente en el 
código. Por otra parte, muchos punteros también se suelen utilizar solamente para opera- 
ciones de lectura y, particularmente, los parámetros de una función no se suelen modificar 
sino que simplemente se consultan. 


C++. Tipado. 





Como regla general, se debería delegar en el compilador todo lo posible en relación 
a la detección de errores. 
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El uso de const también es ventajoso respecto a la directiva de preprocesado define, 
ya que permite que el compilador aplique la típica prevención de errores de tipo. Esto 
posibilita detectar errores en tiempo de compilación y evitar problemas potenciales. Ade- 
más, la depuración es mucho más sencilla por el hecho de manejar los nombres simbólicos 
de las constantes. 


3.1.4. Punteros, arrays y estructuras 


Desreferencia Un puntero es una variable que almacena una 

AA aa dirección de memoria, típicamente la dirección de 
acceso al objeto al que señala un , , : A e 

puntero es una de las operaciones fun- otra variable. Si p contiene la dirección de q, en- 

damentales y se denomina indirección tonces p apunta a q. Los punteros se declaran igual 

o desreferencia, indistintamente. que el resto de variables y están asociados a un ti- 


po específico, el cual ha de ser válido en C++. Un 
ejemplo de declaración de puntero a entero es 


int x*ip; 


En el caso de los punteros, el operador unario * es el utilizado para desreferenciarlos 
y acceder a su contenido, mientras que el operador unario é se utiliza para acceder a la 
dirección de memoria de su operando. Por ejemplo, 


edadptr = dedad; 


asigna la dirección de memoria de la variable edad a la variable edadptr. Recuerde que 
con el operador * es posible acceder al contenido de la variable a la que apunta un puntero. 
Por ejemplo, 


miEdad = *edadptr 


Indirección múltiple permite almacenar el contenido de edad en miE- 
dad. 


Un puntero a puntero es un caso de 

indirección múltiple. El primer punte- En C++ existe una relación muy estrecha entre 
Le One la dre cio nde A ebnaide los punteros y los arrays, siendo posible intercam- 
otro puntero, mientras que éste contie- . y e . 

ela ditección de miémoña deiñavas biarlos en la mayoría de casos. El siguiente listado 
riable. de código muestra un sencillo ejemplo de indexa- 


ción de un array. 


En la inicialización del bucle for de la línea (19) se aprecia cómo se asigna la dirección 
de inicio del array s al puntero p para, posteriormente, indexar el array mediante p para 
resaltar en mayúsculas el contenido del array una vez finalizada la ejecución del bucle. 
Note que C++ permite la inicialización múltiple. 


Los punteros son enormemente útiles y potentes. Sin embargo, cuando un puntero 
almacena, de manera accidental, valores incorrectos, el proceso de depuración puede re- 
sultar un auténtico quebradero de cabeza. Esto se debe a la propia naturaleza del puntero 
y al hecho de que indirectamente afecte a otros elementos de un programa, lo cual puede 
complicar la localización de errores. 
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Listado 3.2: Indexación de un array 


1 *tinclude <iostream> 
2 using namespace std; 
3 





4 int main () € 

5 

6 char s[20] = "hola mundo"; 
7 char xp; 

8 int i; 


10 for (p =S, i=0; plil; i++) 
11 p[il = toupper(p[il); 

12 

13 cout << s << endl; 

14 

15 return 0; 


17 ) 





uy Cuando el compilador de C++ encuentra una cadena literal, la almacena en la tabla 
de cadenas del programa y genera un puntero a dicha cadena. 











El caso típico tiene lugar cuando un puntero apunta a algún lugar de memoria que no 
debe, modificando datos a los que no debería apuntar, de manera que el programa mues- 
tra resultados indeseables posteriormente a su ejecución inicial. En estos casos, cuando se 
detecta el problema, encontrar la evidencia del fallo no es una tarea trivial, ya que inicial- 
mente puede que no exista evidencia del puntero que provocó dicho error. A continuación 
se muestran algunos de los errores típicos a la hora de manejar punteros [13]. 


1. No inicializar punteros. En el listado que se muestra a continuación, p contiene una 
dirección desconocida debido a que nunca fue definida. En otras palabras, no es posible 
conocer dónde se ha escrito el valor contenido en edad. 


Listado 3.3: Primer error típico. No inicializar punteros. 





int main () € 
int edad, *p; 


edad = 23; 
xp = edad; // p? 


return 0; 


, 


0 JO0UBAWNEA 


En un programa que tenga una mayor compleji- Punteros y funciones 
dad, la probabilidad de que p apunte a otra parte de 


Recuerde que es posible utilizar pun- 


dicho programa se incrementa, con la más que pro- teros a funciones, es decir, se puede re- 
bable consecuencia de alcanzar un resultado desas- cuperar la dirección de memoria de una 
troso. función para, posteriormente, llamarla. 
o Este tipo de punteros se utilizan para 

2. Comparar punteros de forma no válida. manejar rutinas que se puedan aplicar a 

La comparación de punteros es, generalmente, in- distintos tipos de objetos, es decir, para 


válida y puede causar errores. En otras palabras, no Manejar el polimorfismo. 
se deben realizar suposiciones sobre qué dirección 
de memoria se utilizará para almacenar los datos, si siempre será dicha dirección o si dis- 
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tintos compiladores tratarán estos aspectos del mismo modo. No obstante, si dos punteros 
apuntan a miembros del mismo arreglo, entonces es posible compararlos. El siguiente 
fragmento de código muestra un ejemplo de uso incorrecto de punteros en relación a este 
tipo de errores. 





No olvide que una de las claves para garantizar un uso seguro de los punteros consiste 
YN en conocer en todo momento hacia dónde están apuntando. 











Listado 3.4: Segundo error típico. Comparación incorrecta de punteros. 





1 int main () € 
2 int s[10]; 
3 int t[10]; 
4 int *p, *q; 
5 
6 
7 
8 


p=s; 
q=t; 


9 if íp<a) 


10 1 A 
11 , 

12 

13 return 0; 
14 y 


3. Olvidar el reseteo de punteros. El siguiente listado de código muestra otro error 
típico, que se puede resumir en no controlar el comportamiento de un puntero. Básica- 
mente, la primera vez que se ejecuta el bucle, p apunta al comienzo de s. Sin embargo, en 
la segunda iteración p continua incrementándose debido a que su valor no se ha estable- 
cido al principio de s. La solución pasa por mover la línea (11) al bucle do-while. 


Listado 3.5: Tercer error típico. Olvidar el reseteo de un puntero. 


1 Hinclude <iostream> 
2 Htinclude <cstdio> 

3 *tinclude <cstring> 
4 using namespace std; 
5 

6 int main () X 


8 char s[100]; 


9 char *p; 

10 

11 p=s; 

12 

13 do ( 

14 cout << "Introduzca una cadena... ”; 
15 fgets(p, 100, stdin); 
16 

17 while (xp) 

18 cout << *p++ << " "; 
19 

20 cout << endl; 

21 jwhile (strcmp(s, "fin")); 
22 

23 return 0; 

24 
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Finalmente, una estructura es un tipo agregado de datos que se puede definir como 
una colección de variables que mantienen algún tipo de relación lógica. Obviamente, antes 
de poder crear objetos de una determinada estructura, ésta ha de definirse. 


El listado de código siguiente muestra un ejemplo de declaración de estructura y de su 
posterior manipulación mediante el uso de punteros. Recuerde que el acceso a los campos 
de una estructura se realiza mediante el operador flecha -> en caso de acceder a ellos 
mediante un puntero, mientras que el operador punto . se utiliza cuando se accede de 
manera directa. 


Nótese el uso del modificador const en el se- 
gundo parámetro de la función modificar_nombre Alas de patera y cop puede da 
que, en este caso, se utiliza para informar al com- lugar a confusión. Recuerde que const 
pilador de que dicha variable no se modificará in- siempre se refiere a lo que se encuentra 
ternamente en dicha función. Asimismo, en dicha inmediatamente a la derecha. Así, int* 
función se hace uso del operador $: en relación ala “on pes un puntero constante, pero 

R Ao 2 no así los datos a los que apunta. 
variable nuevo_nombre. En la siguiente subsección 
se define y explica un nuevo concepto que C++ proporciona para la especificación de 
parámetros y los valores de retorno: las referencias. 


Punteros y const 


*tinclude <iostream> 
using namespace std; 


struct persona f 
string nombre; 
int edad; 

$; 


void modificar_nombre (persona *p, const strings nuevo_nombre); 


int main () € 
persona p; 
persona *q; 


p.nombre = "Luis"; 
p.edad = 23; 
q = Sp; 


cout << q->nombre << endl; 
modificar_nombre(q, "Sergio"); 
cout << q->nombre << endl; 


return 0; 


, 


void modificar_nombre (persona *p, const stringé nuevo_nombre) 4 
p->nombre = nuevo_nombre; 


J 


3.1.5. Referencias y funciones 


En general, existen dos formas de pasar argumentos a una función. La primera se 
denomina paso por valor y consiste en pasar una copia del valor del argumento como 
parámetro a una función. Por lo tanto, los cambios realizados por la función no afectan 
a dicho argumento. Por otra parte, el paso por referencia permite la copia de la direc- 
ción del argumento (y no su valor) en el propio parámetro. Esto implica que los cambios 
efectuados sobre el parámetro afectan al argumento utilizado para realizar la llamada a la 
función. 
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Por defecto, C++ utiliza el paso por valor. Sin embargo, el paso por referencia se pue- 
de realizar utilizando punteros, pasando la dirección de memoria del argumento externo 
a la función para que ésta lo modifique (si así está diseñada). Este enfoque implica hacer 
un uso explícito de los operadores asociados a los punteros, lo cual implica que el pro- 
gramador ha de pasar las direcciones de los argumentos a la hora de llamar a la función. 
Sin embargo, en C++ también es posible indicar de manera automática al compilador que 
haga uso del paso por referencia: mediante el uso de referencias. 


Paso de parámetros Una referencia es simplemente un nombre al- 
n PAN ternativo para un objeto. Este concepto tan suma- 
Es muy importante distinguir correc- 


tamente entre paso de parámetros por mente simple es en realidad extremadamente útil 
valor y por referencia para obtener el para gestionar la complejidad. Cuando se utiliza 
comportamiento deseado en un progra- una referencia, la dirección del argumento se pasa 
ma y para garantizar que la eficiencia automáticamente a la función de manera que, den- 
del mismo no se vea penalizada. a : : 
tro de la función, la referencia se desreferencia au- 
tomáticamente, sin necesidad de utilizar punteros. Las referencias se declaran precediendo 
el operador $: al nombre del parámetro. 





Las referencias son muy parecidas a los punteros. Se refieren a un objeto de manera 
y que las operaciones afectan al objeto al cual apunta la referencia. La creación de 
referencias, al igual que la creación de punteros, es una operación muy eficiente. 











El siguiente listado de código muestra la típica función swap implementada mediante 
el uso de referencias. Como se puede apreciar, los parámetros pasados por referencia no 
hacen uso en ningún momento del operador *, como ocurre con los punteros. En realidad, 
el compilador genera automáticamente la dirección de los argumentos con los que se 
llama a swap, desreferenciando a ambos. 


ttinclude <iostream> 
using namespace std; 


void swap (int Ga, int £b); 


int main () 4 
int x=7, y = 13; 


cout << "[" << x << ", " << y << "]" << endl; // Imprime [7, 13]. 
swap(X, y); 

cout << "[" << x << ", " << y << "]" << endl; // Imprime [13, 7]. 
return 0; 


void swap (int €a, int 8€b) ( 
int aux; 


aux = a; // Guarda el valor al que referencia a. 
a=b; // Asigna el valor de ba a. 
b = aux; // Asigna el valor de aux a b. 
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En C++, existen ciertas diferencias relevantes entre referencias y punteros [3]: 


A la hora de trabajar con una referencia, la sintaxis utilizada es la misma que con 
los objetos. En otras palabras, en lugar de desreferenciar con el operador flecha ->, 
para acceder a variables y funciones se utiliza el operador punto. 


Las referencias sólo se pueden inicializar una vez. Por el contrario, un puntero pue- 
de apuntar a un determinado objeto y, posteriormente, apuntar a otro distinto. Sin 
embargo, una vez inicializada una referencia, ésta no se puede cambiar, compor- 
tándose como un puntero constante. 


Las referencias han de inicializarse tan pronto como sean declaradas. Al contra- 
rio que ocurre con los punteros, no es posible crear una referencia y esperar para 
después inicializarla. 


Las referencias no pueden ser nulas, como consecuencia directa de los dos puntos 
anteriores. Sin embargo, esto no quiere decir que el elemento al que referencian 
siempre sea válido. Por ejemplo, es posible borrar el objeto al que apunta una refe- 
rencia e incluso truncarla mediante algún molde para que apunte a null. 


Las referencias no se pueden crear o eliminar como los punteros. En ese sentido, 
son iguales que los objetos. 


Las funciones también pueden devolver referencias. En C++, una de las mayores uti- 
lidades de esta posibilidad es la sobrecarga de operadores. Sin embargo, en el listado que 
se muestra a continuación se refleja otro uso potencial, debido a que cuando se devuelve 
una referencia, en realidad se está devolviendo un puntero implícito al valor de retorno. 
Por lo tanto, es posible utilizar la función en la parte izquierda de una asignación. 


Como se puede apreciar en el siguiente listado, 
la función £ devuelve una referencia a un valor en 


Funciones y referencias 


En una función, las referencias se pue- 


punto flotante de doble precisión, en concreto a la den utilizar como parámetros de entra- 
variable global valor. La parte importante del códi- da o como valores de retorno. 

go está en la línea (5), en la que valor se actualiza 

a 7,5, debido a que la función devuelve dicha referencia. 


Aunque se discutirá más adelante, las referencias también se pueden utilizar para de- 
volver objetos desde una función de una manera eficiente. Sin embargo, hay que ser cui- 
dadoso con la referencia a devolver, ya que si se asigna a un objeto, entonces se creará 
una copia. El siguiente fragmento de código muestra un ejemplo representativo vincula- 
do al uso de matrices de 16 elementos, estructuras de datos típicamente utilizada en el 
desarrollo de videojuegos. 


const Matrix4x4 £GameScene: :getCameraRotation () const 


t 
7 


return c_rotation; // Eficiente. Devuelve una referencia. 


// Cuidado! Se genera una copia del objeto. 
Matrix4x4 rotation = camera.getCameraRotation; 


// Eficiente. 
Matrix4x4 £$rotation = camera.getCameraRotation; 
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Htinclude <iostream> 
using namespace std; 


double á¿f (); 
double valor = 10.0; 


int main () £ 
double nuevo_valor; 


cout << f() << endl; 
nuevo_valor = f(); 
cout << nuevo_valor << endl; 


fO =7.5; 
cout << f() << endl; 


return 0; 


double ¿f () £ return valor; ) 


Las ventajas de las referencias sobre los punteros se pueden resumir en que utili- 
zar referencias es una forma de más alto nivel de manipular objetos, ya que permite al 
desarrollador olvidarse de los detalles de gestión de memoria y centrarse en la lógica del 
problema a resolver. Aunque pueden darse situaciones en las que los punteros son más 
adecuados, una buena regla consiste en utilizar referencias siempre que sea posible, ya 
que su sintaxis es más limpia que la de los punteros y su uso es menos proclive a errores. 





Siempre que sea posible, es conveniente utilizar referencias, debido a su sencillez, 
manejabilidad y a la ocultación de ciertos aspectos como la gestión de memoria. 











Quizá el uso más evidente de un puntero en detrimento de una referencia consiste en la 
creación o eliminación de objetos de manera dinámica. En este caso, el mantenimiento de 
dicho puntero es responsable de su creador. Si alguien hace uso de dicho puntero, debería 
indicar explícitamente que no es responsable de su liberación. 


Por otra parte, si se necesita cambiar el objeto al que se referencia, entonces también 
se hace uso de punteros, ya que las referencias no se pueden reasignar. En otros casos, el 
desarrollador también puede asumir el manejo de un puntero nulo, devolviéndolo cuando 
una función generó algún error o incluso para manejar parámetros que sean opcionales. 
En estos casos, las referencias tampoco se pueden utilizar. 


Finalmente, otra razón importante para el manejo de punteros en lugar de referencias 
está vinculada a la aritmética de punteros, la cual se puede utilizar para iterar sobre una 
región de memoria. Sin embargo, este mecanismo de bajo nivel tiene el riesgo de generar 
bugs y su mantenimiento puede ser tedioso. En general, debería evitarse cuando así sea 
posible. En la práctica, la aritmética de punteros se puede justificar debido a su elevada 
eficiencia en lugar de realizar una iteración que garantice la integridad de los tipos [3]. 
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3.2. Clases 


3.2.1. Fundamentos básicos 


En el ámbito de la POO, las clases representan una manera de asociar datos con fun- 
cionalidad. Los objetos son las instancias específicas de una clase, de manera que cada 
una tiene sus propios datos pero todas ellas comparten la misma funcionalidad a nivel de 
clase. 


La parte de datos en una clase de C++ no difie- 
re de una estructura en C. Sin embargo, C++ ofrece 
tres niveles de acceso a los datos: públicos, priva- 
dos o protegidos. Por defecto, los miembros de una 
clase son privados, mientras que en una estructura 
son públicos. 


Recuerde que los objetos creados den- 
tro de un bloque se destruyen cuando 
dicho bloque se abandona por el flujo 
del programa. Por el contrario, los ob- 
jetos globales se destruyen cuando el 
programa finaliza su ejecución. 


Debido a que la mayoría de los objetos requie- 
ren una inicialización de su estado, C++ permite inicializar los objetos cuando estos son 
creados mediante el uso de constructores. Del mismo modo, C++ contempla el concepto 
de destructor para contemplar la posibilidad de que un objeto realice una serie de ope- 
raciones antes de ser destruido. El siguiente listado de código muestra la especificación 
de una clase en C++ con los miembros de dicha clase, su visibilidad, el constructor, el 
destructor y otras funciones. 


class Figura 

1 

public: 
Figura (double i, double j); 
Figura (); 


void setDim (double i, double j); 
double getX () const; 
double getY () const; 


protected: 
double _x, _y; 
y; 


Note cómo las variables de clase se definen como protegidas, es decir, con una visibi- 
lidad privada fuera de dicha clase a excepción de las clases que hereden de Figura, tal y 
como se discutirá en la sección 3.3.1. El constructor y el destructor comparten el nombre 
con la clase, pero el destructor tiene delante el símbolo -. 


El resto de funciones sirven para modificar y Paso por referencia 


acceder al estado de los objetos instanciados a par- 
tir de dicha clase. Note el uso del modificador const 
en las funciones de acceso getX() y getY() para in- 
formar de manera explícita al compilador de que 
dichas funciones no modifican el estado de los ob- 


Recuerde utilizar parámetros por refe- 
rencia const para minimizar el número 
de copias de los mismos. El rendimien- 
to mejorará considerablemente. 


jetos. A continuación, se muestra la implementación de las funciones definidas en la clase 


Figura. 
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Listado 3.11: Clase Figura (implementación) 


ttinclude "Figura.h" 


Figura: : Figura 
(double i, double j) 


x=; 
y =]; 


10 Figura::-Figura () 
11 ( 
12 ) 


14 void 

15 Figura: :setDim 

16 (double i, double j) 
17 ( 

18 Xx = 1; 

19 -y=]; 

20 y 

21 

22 double 

23 Figura::getX () const 
24 £ 

25 return _x; 

26 y 

27 

28 double 

29 Figura::getY () const 
30 £ 

31 return _y; 

32 ) 


Uso de inline 


El modificador inline se suele incluir 
después de la declaración de la función 
para evitar líneas de código demasiado 
largas (siempre dentro del archivo de 
cabecera). Sin embargo, algunos com- 
piladores obligan a incluirlo en ambos 
lugares. 


Antes de continuar discutiendo más aspectos de 
las clases, resulta interesante introducir el concep- 
to de funciones en línea (inlining), una técnica que 
puede reducir la sobrecarga implícita en las llama- 
das a funciones. Para ello, sólo es necesario incluir 
el modificador inline delante de la declaración de 
una función. Esta técnica permite obtener exacta- 
mente el mismo rendimiento que el acceso directo 


a una variable sin desperdiciar tiempo en ejecutar la llamada a la función, interactuar con 
la pila del programa y volver de dicha función. 


Las funciones en línea no se pueden usar indiscriminadamente, ya que pueden degra- 
dar el rendimiento de la aplicación fácilmente. En primer lugar, el tamaño del ejecutable 
final se puede disparar debido a la duplicidad de código. Así mismo, la caché de código 
también puede hacer que dicho rendimiento disminuya debido a las continuas penalizacio- 
nes asociadas a incluir tantas funciones en línea. Finalmente, los tiempos de compilación 
se pueden incrementar en grandes proyectos. 
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Recuerde estructurar adecuademente su código y seguir un convenio de nombrado 
que facilite su mantenibilidad. Si se integra en un proyecto activo, procure seguir el 
convenio previamente adoptado. 











Al igual que ocurre con otros tipos de datos, los objetos también se pueden manipular 
mediante punteros. Simplemente se ha de utilizar la misma notación y recordar que la 
aritmética de punteros también se puede usar con objetos que, por ejemplo, formen parte 
de un array. 





Una buena regla para usar de manera adecuada el modificador inline consiste en 
evitar su uso hasta prácticamente completar el desarrollo de un proyecto. A con- 
tinuación, se puede utilizar alguna herramienta de profiling para detectar si alguna 

uy función sencilla está entre las más utilidas. Este tipo de funciones son candidatas 
potenciales para modificarlas con inline y, en consecuencia, elementos para mejorar 
el rendimiento del programa. 











Para los objetos creados en memoria dinámica, el operador new invoca al constructor 
de la clase de manera que dichos objetos existen hasta que explícitamente se eliminen con 
el operador delete sobre los punteros asociados. A continuación se muestra un listado de 
código que hace uso de la clase Figura previamente introducida. 


Htinclude <iostream> 
include "Figura.h" 
using namespace std; 


int main () € 
Figura x*f1; 
f1 = new Figura (1.0, 0.5); 


cout << "[" << f1->getX() << ", " << fl->getY() << "]" << endl; 


delete fl; 
return 0; 


3.2.2. Aspectos específicos de las clases 


En esta subsección se discutirán algunos aspectos de C++ relacionados con el concep- 
to de clase que resultan muy útiles en una gran variedad de situaciones y pueden contribuir 
a mejorar la calidad y la mantenibilidad del código fuente generado por un desarrollador. 


En primer lugar, se discutirá el concepto de función amiga de una clase. Un función 
amiga de una o varias clases, especificada así con el modificador friend y sin ser una de 
sus funciones miembro, puede acceder a los miembros privados de la misma. Aunque en 
principio puede parecer que esta posibilidad no ofrece ninguna ventaja sobre una función 
miembro, en realidad sí que puede aportar beneficios desde el punto de vista del diseño. 
Por ejemplo, este tipo de funciones pueden ser útiles para sobrecargar ciertos tipos de 
operadores y pueden simplificar la creación de algunas funciones de entrada/salida. 
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Un uso bastante común de las funciones amigas se da cuando existen dos o más clases 
con miembros que de algún modo están relacionados. Por ejemplo, imagine dos clases 
distintas que hacen uso de un recurso común cuando se da algún tipo de evento externo. 
Por otra parte, otro elemento del programa necesita conocer si se ha hecho uso de dicho 
recurso antes de poder utilizarlo para evitar algún tipo de inconsistencia futura. En este 
contexto, es posible crear una función en cada una de las dos clases que compruebe, 
consultado una variable booleana, si dicho recurso fue utilizado, provocando dos llamadas 
independientes. Si esta situación se da continuamente, entonces se puede llegar a producir 
una sobrecarga de llamadas. 


Por el contrario, el uso de una función amiga permitiría comprobar de manera directa 
el estado de cada objeto mediante una única llamada que tenga acceso a las dos clases. 
En este tipo de situaciones, las funciones amigas contribuyen a un código más limpio y 
mantenible. El siguiente listado de código muestra un ejemplo de este tipo de situaciones. 


const int USADO = 1; 
const int NO_USADO = 0; 


class B; 


class A X 
int _estado; 


public: 
A() L£_estado = NO_USADO; y 
void setEstado (int estado) (_estado = estado;) 
friend int usado (A a, B b); 

y; 


class Bf 
int _estado; 


public: 
B() £ estado = NO_USADO;) 
void setEstado (int estado) (_estado = estado;) 
friend int usado (A a, B b); 

y; 


int usado (A a, Bb) f 
return (a._estado || b._estado); 


En el ejemplo, línea (21), se puede apreciar cómo la función recibe dos objetos como 
parámetros. Al contrario de lo que ocurre en otros lenguajes como Java, en C++ los ob- 
jetos, por defecto, se pasan por valor. Esto implica que en realidad la función recibe una 
copia del objeto, en lugar del propio objeto con el que se realizó la llamada inicial. Por 
tanto, los cambios realizados dentro de la función no afectan a los argumentos. Aunque el 
paso de objetos es un procedimiento sencillo, en realidad se generan ciertos eventos que 
pueden sorprender inicialmente. El siguiente listado de código muestra un ejemplo. 
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Listado 3.14: Paso de objetos por valor 


*tinclude <iostream> 
using namespace std; 


1 

2 

3 

4 class Af 

5 int _valor; 
6 public: 

7 A(int valor): _valor(valor) 4 

8 cout << "Construyendo..." << endl; 
9 7) 

10 -A() [ 

11 cout << "Destruyendo..." << endl; 
12 J 

13 

14 int getValor () const ( 

15 return _valor; 

16 J 

17 y; 

18 

19 void mostrar (A a) £ 

20 cout << a.getValor() << endl; 

21 ) 


23 int main () £ 
24 A a(7); 

25 mostrar(a); 
26 return 0; 


La salida del programa es la siguiente: 


Construyendo... 
7 
Destruyendo... 
Destruyendo... 


Como se puede apreciar, existe una llamada al constructor al crear a (línea (24) y 
dos llamadas al destructor. Como se ha comentado antes, cuando un objeto se pasa a 
una función, entonces se crea una copia del mismo, la cual se destruye cuando finaliza 
la ejecución de la función. Ante esta situación surgen dos preguntas: 1) ¿se realiza una 
llamada al constructor? y 11) ¿se realiza una llamada al destructor? 


En realidad, lo que ocurre cuando se pasa un objeto a una función es que se llama al 
constructor de copia, cuya responsabilidad consiste en definir cómo se copia un objeto. 
Si una clase no tiene un constructor de copia, entonces C++ proporciona uno por defecto, 
el cual crea una copia bit a bit del objeto. En realidad, esta decisión es bastante lógica, ya 
que el uso del constructor normal para copiar un objeto no generaría el mismo resultado 
que el estado que mantiene el objeto actual (generaría una copia con el estado inicial). 


Sin embargo, cuando una función finaliza y se ha de eliminar la copia del objeto, 
entonces se hace uso del destructor debido a que la copia se encuentra fuera de su ámbito 
local. Por lo tanto, en el ejemplo anterior se llama al destructor tanto para la copia como 
para el argumento inicial. 
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El paso de objetos no siempre es seguro. Por ejemplo, si un objeto utilizado como 
argumento reserva memoria de manera dinámica, liberándola en el destructor, en- 
tonces la copia local dentro de la función liberará la misma región de memoria al 

Le llamar a su destructor. Este tipo de situaciones puede causar errores potenciales en 
un programa. La solución más directa pasa por utilizar un puntero o una referencia 
en lugar del propio objeto. De este modo, el destructor no se llamará al volver de la 
función. 











En el caso de devolver objetos al finalizar la ejecución de una función se puede pro- 
ducir un problema similar, ya que el objeto temporal que se crea para almacenar el valor 
de retorno también realiza una llamada a su destructor. La solución pasa por devolver un 
puntero o una referencia, pero en casos en los que no sea posible el constructor de copia 
puede contribuir a solventar este tipo de problemas. 





A No devuelva punteros o referencias a variables locales. 











El constructor de copia representa a un tipo especial de sobrecarga del constructor 
y se utiliza para gestionar de manera adecuada la copia de objetos. Como se ha discutido 
anteriormente, la copia exacta de objetos puede producir efectos no deseables, especial- 
mente cuando se trata con asignación dinámica de memoria en el propio constructor. 


Recuerde que C++ contempla dos tipos de situaciones distintas en las que el valor de 
un objeto se da a otro: la asignación y la inicialización. Esta segunda se pueda dar de tres 
formas distintas: 


= Cuando un objeto inicializa explícitamente a otro, por ejemplo en una declaración. 
= Cuando la copia de un objeto se pasa como parámetro en una función. 


= Cuando se genera un objeto temporal, por ejemplo al devolverlo en una función. 


(his y funciones amigas Es importante resaltar que el constructor de co- 
Eds Tinciones piba no maño anal pia sólo se aplica en las inicializaciones y no en las 
puntero this, debido a que no son asignaciones. El siguiente listado de código mues- 
miembros de una clase. tra un ejemplo de implementación del constructor 


de copia, en el que se gestiona adecuadamente la 
asignación de memoria dinámica en el constructor. Dicho ejemplo se basa en el discutido 
anteriormente sobre el uso de paso de objetos por valor. 


Como se puede apreciar, el constructor normal hace una reserva dinámica de memoria. 
Por lo tanto, el constructor de copia se utiliza para que, al hacer la copia, se reserve nueva 
memoria y se asigne el valor adecuado a la variable de clase. 


La salida del programa es la siguiente: 


Construyendo... 
Constructor copia... 
7 

Destruyendo... 
Destruyendo... 


Finalmente, antes de pasar a la sección de sobrecarga de operadores, C++ contempla, 
al igual que en otros lenguajes de programación, el uso de this como el puntero al objeto 
que invoca una función miembro. Básicamente, dicho puntero es un parámetro implícito 
a todas las funciones miembro de una clase. 
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Listado 3.15: Uso del constructor de copia 


1 *tinclude <iostream> 
2 using namespace std; 


3 

4 class Af 

5 int x_valor; 

6 public: 

7 A(int valor); // Constructor. 

8 A(const A $obj); // Constructor de copia. 
9 -A(); // Destructor. 

10 

11 int getValor () const [ return x*_valor;) 
12 ); 

13 

14 A::A (int valor) £ 

15 cout << "Construyendo..." << endl; 

16 _valor = new int; 

17 *_valor = valor; 

18 ) 

19 

20 A::A (const A Sobj) £ 

ZE cout << "Constructor copia..." << endl; 
22 _valor = new int; 

23 x*_valor = obj.getValor(); 

24 y 

25 

26 A::-A () 4 

27 cout << "Destruyendo..." << endl; 

28 delete _valor; 

29 ) 

30 


31 void mostrar (A a) £ 

32 cout << a.getValor() << endl; 
33 ) 

34 

35 int main () £ 

36 A a(7); 

37 mostrar(a); 

38 return 0; 

39 ) 


3.2.3. Sobrecarga de operadores 


La sobrecarga de operadores permite definir de manera explícita el significado de un 
operador en relación a una clase. Por ejemplo, una clase que gestione la matriculación 
de alumnos podría hacer uso del operador + para incluir a un nuevo alumno. En C++, 
los operadores se pueden sobrecargar de acuerdo a los tipos de clase definidos por el 
usuario. De este modo, es posible integrar nuevos tipos de datos cuando sea necesario. 
La sobrecarga de operadores está muy relacionada con la sobrecarga de funciones, siendo 
necesario definir el significado del operador sobre una determinada clase. 
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El siguiente ejemplo muestra la sobrecarga del operador + en la clase Point3D. 


class Point3D ( 
public: 
Point3D (): 
-X(0), -y(0), -z(0) (7 
Point3D (int x, int y, int z): 
X(x), -y (y), -2(2) (Y 
Point3D operator+ (const Point3D £0p2); 


private: 
int -x, y, -Z; 


y; 


Point3D 

Point3D: :operator+ 

(const Point3D Sop2) 4 
Point3D resultado; 


resultado._x = this->_x + 0p2._x; 
resultado._y = this->_y + 0p2._y; 
resultado._z = this->_z + 0p2._z; 


return resultado; 


Como se puede apreciar, el operador + de la clase Point3D permite sumar una a 
una los distintos componentes vinculados a las variables miembro para, posteriormente, 
devolver el resultado. Es importante resaltar que, aunque la operación está compuesta de 
dos operandos, sólo se pasa un operando por parámetro. El segundo operando es implícito 
y se pasa mediante this. 





Existen ciertas restricciones relativas a la sobrecarga de operadores: no es posible 
alterar la precedencia de cualquier operador, no es posible alterar el número de ope- 

uy randos requeridos por un operador y, en general, no es posible utilizar argumentos 
por defecto. 





En C++, también es posible sobrecargar operadores unarios, como por ejemplo ++. 
En este caso particular, no sería necesario pasar ningún parámetro de manera explícita, ya 
que la operación afectaría al parámetro implícito this. 


Otro uso importante de la sobrecarga de operadores está relacionado con los proble- 
mas discutidos en la sección 3.2.2. C++ utiliza un constructor de copia por defecto que 
se basa en realizar una copia exacta del objeto cuando éste se pasa como parámetro a una 
función, cuando se devuelve de la misma o cuando se inicializa. Si el constructor de una 
clase realiza una reserva de recursos, entonces el uso implícito del constructor de copia 
por defecto puede generar problemas. La solución, como se ha comentado anteriormente, 
es el constructor de copia. 
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Sin embargo, el constructor de copia sólo se utiliza en las inicializaciones y no en 
las asignaciones. En el caso de realizar una asignación, el objeto de la parte izquierda 
de la asignación recibe por defecto una copia exacta del objeto que se encuentra a la 
derecha de la misma. Esta situación puede causar problemas si, por ejemplo, el objeto 
realiza una reserva de memoria. Si, después de una asignación, un objeto altera o libera 
dicha memoria, el segundo objeto se ve afectado debido a que sigue haciendo uso de dicha 
memoria. La solución a este problema consiste en sobrecargar el operador de asignación. 


El siguiente listado de código muestra la implementación de una clase en la que se 
reserva memoria en el constructor, en concreto, un array de caracteres. 


*tinclude <iostream> 
Htinclude <cstring> 
*tinclude <cstdlib> 
using namespace std; 


class A [ 
char x_valor; 
public: 
A() (valor = 0;) 
A(const A $obj); // Constructor de copia. 
-A() fif(_valor) delete [] _valor; 
cout << "Liberando..." << endl;) 


void mostrar () const (cout << _valor << endl;) 
void set (char x*valor); 


y; 


A::A(const A Sobj) 4 
_valor = new char[strlen(obj._valor) + 1]; 
strcpy(_valor, obj._valor); 


J 


void A::set (char xvalor) f 
delete [] _valor; 
_valor = new char[strlen(valor) + 1]; 
strcpy(_valor, valor); 


7 


El constructor de copia se define entre las líneas (18) y (21), reservando una nueva región 
de memoria para el contenido de _valor y copiando el mismo en la variable miembro. Por 
otra parte, las líneas muestran la implementación de la función set, que modifica el 
contenido de dicha variable miembro. 


El siguiente listado muestra la implementación de la función entrada, que pide una 
cadena por teclado y devuelve un objeto que alberga la entrada proporcionada por el 
usuario. 


En primer lugar, el programa se comporta adecuadamente cuando se llama a entrada, 
particularmente cuando se devuelve la copia del objeto a, utilizando el constructor de 
copia previamente definido. Sin embargo, el programará abortará abruptamente cuando el 
objeto devuelto por entrada se asigna a obj en la función principal. Recuerde que en este 
caso se efectua una copia idéntica. El problema reside en que obj.valor apunta a la misma 
dirección de memoria que el objeto temporal, y éste último se destruye después de volver 
desde entrada, por lo que obj.valor apunta a memoria que acaba de ser liberada. Además, 
obj.valor se vuelve a liberar al finalizar el programa. 
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Listado 3.18: Sobrecarga del operador de asignación (cont.) 


A entrada () X 
char entrada[80]; 
Aa; 





1 
2 
3 
4 
5 cout << "Introduzca texto... "; 
6 cin >> entrada; 

7 

8 a.set(entrada); 

9 return a; 

10 ) 


12 int main () 4 

13 A obj; 

14 obj = entrada(); // Fallo. 
15 obj.mostrar(); 

16 return 0; 


Para solucionar este problema se sobrecarga el operador de asignación de copia en la 
clase en cuestión, tal y como muestra el siguiente listado de código. 


Listado 3.19: Sobrecarga del operador de asignación (cont.) 


AS A: :operator= (const A Sobj) 4 
if (strlen(obj._valor) > strlen(_valor)) £ 
delete [] _valor; 
_valor = new char[strlen(obj._valor) + 1] 


y 
strcpy(_valor, obj._valor); 


return *this; 


O000=3D0UAUNA 


pan 
=— 


En la función anterior se comprueba si la variable miembro tiene suficiente memoria 
para albergar el objeto pasado como parámetro (línea (2). Si no es así, libera memoria y 
reserva la que sea necesaria para, posteriormente, devolver la copia de manera adecuada. 


Finalmente, resulta especialmente relevante destacar que C++ permite la sobrecarga 
de cualquier operador, a excepción de new, delete, ->, ->* y el operador coma, que re- 
quieren otro tipo de técnicas. El resto de operadores se sobrecargan del mismo modo que 
los discutidos en esta sección. 


3.3. Herencia y polimorfismo 


La herencia representa uno de los conceptos fundamentales de la POO debido a que 
permite la creación de jerarquías de elementos. De este modo, es posible crear una clase 
base que define los aspectos o características comunes de una serie de elementos relacio- 
nados. A continuación, esta clase se puede extender para que cada uno de estos elementos 
añada las características únicas que lo diferencian del resto. 


En C++, las clases que son heredadas se definen como clases base, mientras que las 
clases que heredan se definen como clases derivadas. Una clase derivada puede ser a 
su vez clase base, posibilitando la generación de jerarquías de clases. Dichas jerarquías 
permiten la creación de cadenas en las que los eslabones están representados por clases 
individuales. 


3.3, Herencia y polimorfismo [87] 





Polimorfismo Por otra parte, el polimorfismo es el término 
A polinomio seus defi coma que describe el proceso mediante el cual distintas 
una interfaz, múltiples métodos y re- implementaciones de una misma función se utili- 
presenta una de los aspectos clave de zan bajo un mismo nombre. Así, se garantiza un 
la POO. acceso uniforme a la funcionalidad, aunque las ca- 


racterísticas de cada operación sean distintas. 


En C++, el polimorfismo está soportado tanto en tiempo de compilación como en 
tiempo de ejecución. Por una parte, la sobrecarga de operadores y de funciones son ejem- 
plos de polimorfismo en tiempo de compilación. Por otra parte, el uso de clases derivadas 
y de funciones virtuales posibilitan el polimorfismo en tiempo de ejecución. 


3.3.1. Herencia 


El siguiente listado de código muestra la clase base Vehículo que, desde un punto 
de vista general, define un medio de transporte por carretera. De hecho, sus variables 
miembro son el número de ruedas y el número de pasajeros. 


Listado 3.20: Clase base Vehículo 


class Vehiculo ( 
int _ruedas; // Privado. No accesible en clases derivadas. 
int _pasajeros; 


1 
2 
3 
4 
5 public: 

6 void setRuedas (int ruedas) [(_ruedas = ruedas;) 

7 int getRuedas () const (return _ruedas;) 

8 void setPasajeros (int pasajeros) (_pasajeros = pasajeros;) 
9 int getPasajeros () const (return _pasajeros;) 

0 


10 ); 


La clase base anterior se puede extender para definir coches con una nueva caracterís- 
tica propia de los mismos, como se puede apreciar en el siguiente listado. 


Listado 3.21: Clase derivada Coche 


*tinclude <iostream> 
*tinclude "Vehiculo.cpp" 
using namespace std; 


int _PMA; 
public: 


void setPMA (int PMA) (_PMA = PMA; 
10 int getPMA () const (return _PMA;) 


1 
2 
3 
4 
5 class Coche : public Vehiculo f 
6 
Y 
8 
9 


11 

12 void mostrar () const ( 

13 cout << "Ruedas: " << getRuedas() << endl; 

14 cout << "Pasajeros: " << getPasajeros() << endl; 
15 cout << "PMA: " << _PMA << endl; 

16 J 
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En este ejemplo no se han definido los cons- 


Herencia y acceso a E : ] 
tructores de manera intencionada para discutir el 


El modificador de acceso cuando se usa 


herencia es opcional. Sin embargo, si acceso a los miembros de la clase. Como se puede 
éste se especifica ha de ser public, pro- apreciar en la línea (5) del siguiente listado, la cla- 
tected o private. Por defecto, su valor se Coche hereda de la clase Vehículo, utilizando el 


es private si la clase derivada es efscti- operador :. La palabra reservada public delante de 
vamente una clase. Si la clase derivada 


es una estructura, entonces su valor por Vehículo determina el tipo de acceso. En este ca- 

defecto es public. so concreto, el uso de public implica que todos los 

miembros públicos de la clase base serán también 

miembros públicos de la clase derivada. En otras palabras, el efecto que se produce equi- 

vale a que los miembros públicos de Vehículo se hubieran declarado dentro de Coche. Sin 

embargo, desde Coche no es posible acceder a los miembros privados de Vehículo, como 
por ejemplo a la variable _ruedas. 


El caso contrario a la herencia pública es la herencia privada. En este caso, cuando la 
clase base se hereda con private, entonces todos los miembros públicos de la clase base 
se convierten en privados en la clase derivada. 


Además de ser público o privado, un miembro de clase se puede definir como prote- 
gido. Del mismo modo, una clase base se puede heredar como protegida. Si un miembro 
se declara como protegido, dicho miembro no es accesible por elementos que no sean 
miembros de la clase salvo en una excepción. Dicha excepción consiste en heredar un 
miembro protegido, hecho que marca la diferencia entre private y protected. En esencia, 
los miembros protegidos de la clase base se convierten en miembros protegidos de la clase 
derivada. Desde otro punto de vista, los miembros protegidos son miembros privados de 
una clase base pero con la posibilidad de heredarlos y acceder a ellos por parte de una 
clase derivada. El siguiente listado de código muestra el uso de protected. 


Htinclude <iostream> 
using namespace std; 


class Vehiculo ( 

protected: 
int _ruedas; // Accesibles en Coche. 
int _ pasajeros; 
ES 

$»; 


class Coche : protected Vehiculo £ 


int _PMA; 
public: 
TÍ aca 
void mostrar () const 4 
cout << "Ruedas: " << _ruedas << endl; 


cout << "Pasajeros: << _pasajeros << endl; 
cout << "PMA: " << _PMA << endl; 
+ 
$»; 


Otro caso particular que resulta relevante comentar se da cuando una clase base se 
hereda como privada. En este caso, los miembros protegidos se heredan como miembros 
privados en la clase protegida. 


Sí una clase base se hereda como protegida mediante el modificador de acceso protec- 
ted, entonces todos los miembros públicos y protegidos de dicha clase se heredan como 
miembros protegidos en la clase derivada. 
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Constructores y destructores 


Cuando se hace uso de herencia y se definen constructores y/o destructores de clase, 
es importante conocer el orden en el que se ejecutan en el caso de la clase base y de 
la clase derivada, respectivamente. Básicamente, a la hora de construir un objeto de una 
clase derivada, primero se ejecuta el constructor de la clase base y, a continuación, el 
constructor de la derivada. En el caso de la destrucción de objetos, el orden se invierte, es 
decir, primero se ejecuta el destructor de la clase derivada y, a continuación, el de la clase 
base. 


Otro aspecto relevante está vinculado al paso de 


Inicialización de objetos A 
parámetros al constructor de la clase base desde el 


El constructor de una clase debería 


inicializar idealmente todo el estado constructor de la clase derivada. Para ello, simple- 
de los objetos instanciados. Utilice el mente se realiza una llamada al constructor de la 
constructor de la clase base cuando así clase base, pasando los argumentos que sean nece- 


A6A AESeSanO. sarios. Este planteamiento es similar al utilizado en 


Java mediante super(). Note que aunque una clase derivada no tenga variables miembro, 
en su constructor han de especificarse aquellos parámetros que se deseen utilizar para 
llamar al constructor de la clase base. 





Recuerde que, al utilizar herencia, los constructores se ejecutan en el orden de su de- 
rivación mientras que los destructores se ejecutan en el orden inverso a la derivación. 











3.3.2. Herencia múltiple 


C++ posibilita la herencia múltiple, es decir, permite que una clase derivada herede 
de dos o más clases base. Para ejemplificar la potencia de la herencia múltiple, a conti- 
nuación se plantea un problema que se abordará con distintos enfoques con el objetivo de 
obtener una buena solución de diseño [3]. 


Suponga que es necesario diseñar la clase ObjetoJuego, la cual se utilizará como clase 
base para distintas entidades en un juego, como los enemigos, las cámaras, los ¡tems, 
etc. En concreto, es necesario que todos los objetos del juego soporten funcionalidad 
relativa a la recepción de mensajes y, de manera simultánea, dichos objetos han de poder 
relacionarse como parte de una estructura de árbol. 


El enfoque todo en uno 


Una primera opción de diseño podría consistir en aplicar un enfoque todo en uno, es 
decir, implementar los requisitos previamente comentados en la propia clase ObjetoJuego, 
añadiendo la funcionalidad de recepción de mensajes y la posibilidad de enlazar el objeto 
en cualquier parte del árbol a la propia clase. 


Aunque la simplicidad de esta aproximación es su principal ventaja, en general añadir 
todo lo que se necesita en una única clase no es la mejor decisión de diseño. Si se utiliza 
este enfoque para añadir más funcionalidad, la clase crecerá en tamaño y en complejidad 
cada vez que se integre un nuevo requisito funcional. Así, una clase base que resulta 
fundamental en el diseño de un juego se convertirá en un elemento difícil de utilizar y de 
mantener. En otras palabras, la simplicidad a corto plazo se transforma en complejidad a 
largo plazo. 
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Otro problema concreto con este enfoque es la duplicidad de código, ya que la clase 
ObjetoJuego puede no ser la única en recibir mensajes, por ejemplo. La clase Jugador 
podría necesitar recibir mensajes sin ser un tipo particular de la primera clase. En el caso 
de enlazar con una estructura de árbol se podría dar el mismo problema, ya que otros 
elementos del juego, como por ejemplo los nodos de una escena se podría organizar del 
mismo modo y haciendo uso del mismo tipo de estructura de árbol. En este contexto, 
copiar el código allí donde sea necesario no es una solución viable debido a que complica 
enormemente el mantenimiento y afecta de manera directa a la arquitectura del diseño. 


Enfoque basado en agregación 


La conclusión directa que se obtiene al reflexionar sobre el anterior enfoque es que re- 
sulta necesario diseñar sendas clases, ReceptorMensajes y NodoArbol, para representar la 
funcionalidad previamente discutida. La cuestión reside en cómo relacionar dichas clases 
con la clase ObjetoJuego. 


Una opción inmediata podría ser la agregación, 





Contenedores ; , 
Lia de manera que un objeto de la clase ObjetoJuego 
a aplicación de un esquema basado en B . : 
agregación, de manera que una clase contuviera un objeto de la clase ReceptorMensajes 
contiene elementos relevantes vincula- y otro de la clase NodoArbol, respectivamente. Así, 
dos a su funcionalidad, es en general un la clase ObjetoJuego sería responsable de propor- 
buen diseño. cionar la funcionalidad necesaria para manejarlos 


en su propia interfaz. En términos generales, esta solución proporciona un gran nivel de 
reutilización sin incrementar de manera significativa la complejidad de las clases que se 
extienden de esta forma. 


El siguiente listado de código muestra una posible implementación de este diseño. 


class ObjetoJuego 4 
public: 
bool recibirMensaje (const Mensaje ám); 


ObjetoJuegox getPadre (); 
ObjetoJuegox getPrimerHijo (); 
1 OS 


private: 
ReceptorMensajes *_receptorMensajes; 
NodoArbol x_nodoArbol; 


inline bool recibirMensaje (const Mensaje ám) ( 
return _receptorMensajes->recibirMensaje(m); 


inline ObjetoJuegox getPadre () 4 
return _nodoArbol->getPadre(); 


inline ObjetoJuegox* getPrimerHijo () 4 
return _nodoArbol->getPrimerHijo(); 
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Figura 3.2: Distintas soluciones de diseño para el problema de la clase ObjetoJuego. (a) Uso de agregación. (b) 
Herencia simple. (c) Herencia múltiple. 


La desventaja directa de este enfoque es la generación de un gran número de funciones 
que simplemente llaman a la función de una variable miembro, las cuales han de crearse 
y mantenerse. Si unimos este hecho a un cambio en su interfaz, el mantenimiento se com- 
plica aún más. Así mismo, se puede producir una sobrecarga en el número de llamadas a 
función, hecho que puede reducir el rendimiento de la aplicación. 


Una posible solución a este problema consiste en exponer los propios objetos en lugar 
de envolverlos con llamadas a funciones miembro. Este planteamiento simplifica el man- 
tenimiento pero tiene la desventaja de que proporciona más información de la realmente 
necesaria en la clase ObjetoJuego. Si además, posteriormente, es necesario modificar la 
implementación de dicha clase con propósitos de incrementar la eficiencia, entonces ha- 
bría que modificar todo el código que haga uso de la misma. 


Enfoque basado en herencia simple 


Otra posible solución de diseño consiste en usar Uso de la herencia 


herencia simple, es decir, ObjetoJuego se podría Reudideivaciaheciaia con pas 


declarar como una clase derivada de ReceptorMen- dencia. Un buen truco consiste en pre- 
sajes, aunque NodoArbol quedaría aislado. Si se guntarse si la clase derivada es un tipo 
utiliza herencia simple, entonces una alternativa se- particular de la base. 


ría aplicar una cadena de herencia, de manera que, 
por ejemplo, ArbolNodo hereda de ReceptorMensajes y, a su vez, ObjetoJuego hereda de 
ArbolNodo (ver figura 3.2.b). 


Aunque este planteamiento es perfectamente funcional, el diseño no es adecuado ya 
que resulta bastante lógico pensar que ArbolNodo no es un tipo especial de Receptor- 
Mensajes. Si no es así, entonces no debería utilizarse herencia. Simple y llanamente. Del 
mismo modo, la relación inversa tampoco es lógica. 
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Enfoque basado en herencia múltiple 


La herencia múltiple representa la solución idónea al problema planteado. Realmen- 
te, la herencia múltiple funciona como la herencia simple, pero posibilita que una clase 
derivada herede de dos clases base. En este caso particular, ObjetoJuego podría heredar 
de ReceptorMensajes y de ArbolNodo simultáneamente. Así, la primera clase tendría de 
manera automática la interfaz, las variables miembro y la funcionalidad de las otras dos 
clases. 


class ObjetoJuego: public ReceptorMensajes, public NodoArbol 
public: 
// Funcionalidad necesaria. 


y; 


Desde un punto de vista general, la herencia múltiple puede introducir una serie de 
complicaciones y desventajas, entre las que destacan las siguientes: 


= Ambigiiedad, debido a que las clases base de las que hereda una clase derivada 
pueden mantener el mismo nombre para una función. Para solucionar este proble- 
ma, se puede explicitar el nombre de la clase base antes de hacer uso de la función, 
es decir, ClaseBase:: Funcion. 


= Topografía, debido a que se puede dar la situación en la que una clase derivada 
herede de dos clases base, que a su vez heredan de otra clase, compartiendo todas 
ellas la misma clase. Este tipo de árboles de herencia puede generar consecuencias 
inesperadas, como duplicidad de variables y ambigiedad. Este tipo de problemas 
se puede solventar mediante herencia virtual, concepto distinto al que se estudiará 
en el siguiente apartado relativo al uso de funciones virtuales. 


= Arquitectura del programa, debido a que el uso de la herencia, simple o múltiple, 
puede contribuir a degradar el diseño del programa y crear un fuerte acoplamiento 
entre las distintas clases que la componen. En general, es recomendable utilizar al- 
ternativas como la composición y relegar el uso de la herencia múltiple sólo cuando 
sea la mejor alternativa real. 





Las jerarquías de herencia que forman un diamante, conocidas comúnmente como 
DOD (Diamond Of Death) deberían evitarse y, generalmente, es un signo de un di- 
seño incorrecto. 





3.3.3. Funciones virtuales y polimorfismo 


Como se introdujo al principio de la sección 3.3, en C++ el polimorfismo está so- 
portado tanto en tiempo de compilación como en tiempo de ejecución. La sobrecarga de 
operadores y de funciones son ejemplos de polimorfismo en tiempo de compilación, mien- 
tras que el uso de clases derivadas y de funciones virtuales posibilitan el polimorfismo en 
tiempo de ejecución. Antes de pasar a discutir las funciones virtuales, se introducirá el 
concepto de puntero a la clase base como fundamento básico del polimorfismo en tiempo 
de ejecución. 


3.3. Herencia y polimorfismo 


[93] 





El puntero a la clase base 


En términos generales, un puntero de un determinado tipo no puede apuntar a un 
objeto de otro tipo distinto. Sin embargo, los punteros a las clases bases y derivadas re- 
presentan la excepción a esta regla. En C++, un puntero de una determinada clase base se 
puede utilizar para apuntar a objetos de una clase derivada a partir de dicha clase base. 


Flexibilidad en C++ 


El polimorfismo en C++ es un arma 
muy poderosa y, junto con la herencia, 
permite diseñar e implementar progra- 
mas complejos. 


En el listado de código 3.25 se retoma el ejem- 
plo de uso de herencia entre las clases Vehículo y 
Coche para mostrar el uso de un puntero a una cla- 
se base (Vehículo). Como se puede apreciar en la 
línea (11), el puntero de tipo base Vehículo se utili- 
za para apuntar a un objeto de tipo derivado Coche, 


para, posteriormente, acceder al número de pasajeros en la línea (12). 


Listado 3.25: Manejo de punteros a clase base 


1 *tinclude "Coche.cpp" 

2 

3 int main () £ 

4 Vehiculo xv; // Puntero a objeto de tipo vehículo. 
5 Coche c; // Objeto de tipo coche. 

6 

7 c.setRuedas (4); // Se establece el estado de c. 
8 c.setPasajeros(7); 

9 c.setPMA(1885); 

10 

TL v=á4c; // v apunta a un objeto de tipo coche. 
12 cout << "Pasajeros: " << v->getPasajeros() << endl; 


13 
14 return 0; 
15 ) 


Cuando se utilizan punteros a la clase base, es importante recordar que sólo es posible 
acceder a aquellos elementos que pertenecen a la clase base. En el listado de código 3.26 
se ejemplifica cómo no es posible acceder a elementos de una clase derivada utilizando 


un puntero a la clase base. 


Fíjese cómo en la línea el programa está 


Tipos de casting 


intentando acceder a un elemento particular de la 
clase Coche mediante un puntero de tipo Vehícu- 
lo. Obviamente, el compilador generará un error ya 
que la función getPMA() es específica de la clase 
derivada. Si se desea acceder a los elementos de 
una clase derivada a través de un puntero a la cla- 
se base, entonces es necesario utilizar un molde o 
cast. 


En C++, es preferible utilizar los meca- 
nismos específicamente diseñados para 
realizar castings. En el caso de mane- 
jar herencia simple, se puede utilizar el 
operador static_cast. En el caso de he- 
rencia múltiple, se puede utilizar dyna- 
mic_cast, ya que existen diferentes cla- 
ses base para una misma clase deriva- 
da. 


En la línea (15) se muestra cómo realizar un casting para poder utilizar la funcionalidad 
anteriormente mencionada. Sin embargo, y aunque la instrucción es perfectamente válida, 
es preferible utilizar la nomenclatura de la línea (17), la cual es más limpia y hace uso de 


elementos típicos de C++. 
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Listado 3.26: Manejo de punteros a clase base (cont.) 


1 Hinclude "Coche.cpp" 

Z 

3 int main () £ 

4 Vehiculo xv; // Puntero a objeto de tipo vehículo. 
5 Coche c; // Objeto de tipo coche. 

6 

7 c.setRuedas (4); // Se establece el estado de c. 
8 c.setPasajeros(7); 

9 c.setPMA(1885); 

10 

11 v=ác; // v apunta a un objeto de tipo coche. 
12 


13 cout << v->getPMA() << endl; // ERROR en tiempo de compilación. 
14 
15 cout << ((Cochex)v) ->getPMA() << endl; // NO recomendable. 


16 

17 cout << static_cast<Cochex*>(v)->getPMA() << endl; // Estilo C++. 
18 

19 return 0; 

20 y 


Otro punto a destacar está relacionado con la aritmética de punteros. En esencia, los 
punteros se incrementan o decrementan de acuerdo a la clase base. En otras palabras, 
cuando un puntero a una clase base está apuntando a una clase derivada y dicho puntero se 
incrementa, entonces no apuntará al siguiente objeto de la clase derivada. Por el contrario, 
apuntará a lo que él cree que es el siguiente objeto de la clase base. Por lo tanto, no es 
correcto incrementar un puntero de clase base que apunta a un objeto de clase derivada. 


Finalmente, es importante destacar que, al igual que ocurre con los punteros, una 
referencia a una clase base se puede utilizar para referenciar a un objeto de la clase 
derivada. La aplicación directa de este planteamiento se da en los parámetros de una 
función. 


Uso de funciones virtuales 


La palabra clave virtual Una función virtual es una función declarada 
: a como virtual en la clase base y redefinida en una o 
Una clase que incluya una función vir- 


tual es una clase polimórfica. más clases derivadas. De este modo, cada clase de- 

rivada puede tener su propia versión de dicha fun- 

ción. El aspecto interesante es lo que ocurre cuando se llama a esta función con un puntero 

o referencia a la clase base. En este contexto, C++ determina en tiempo de ejecución qué 

versión de la función se ha de ejecutar en función del tipo de objeto al que apunta el 
puntero. 


3.3. Herencia y polimorfismo 
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*tinclude <iostream> 
using namespace std; 


class Base ( 


public: 

virtual void imprimir () const ( cout << "Soy Base!" << endl; ) 
$; 
class Derivadal : public Base [ 
public: 

void imprimir () const [£ cout << "Soy Derivadal!" << endl; y 
y; 
class Derivada2 : public Base ([ 
public: 

void imprimir () const [ cout << "Soy Derivada2!" << endl; ) 
y; 


int main () £ 
Base *pb, base_obj; 
Derivadal d1_obj; 
Derivada2 d2_obj; 


pb = ábase_obj; 


pb->imprimir(); // Acceso a imprimir de Base. 

pb = ádl_obj; 

pb->imprimir(); // Acceso a imprimir de Derivadal. 
pb = £d2_obj; 

pb->imprimir(); // Acceso a imprimir de Derivada2. 
return 0; 


La ejecución del programa produce la siguiente salida: 


Soy Base! 
Soy Derivadal! 
Soy Derivada2! 


Las funciones virtuales han de ser miembros de la clase en la que se definen, es decir, 
no pueden ser funciones amigas. Sin embargo, una función virtual puede ser amiga de 
otra clase. Además, los destructores se pueden definir como funciones virtuales, mientras 


que en los constructores no. 


Las funciones virtuales se heredan de manera 
independiente del número de niveles que tenga la 
jerarquía de clases. Suponga que en el ejemplo an- 
terior Derivada2 hereda de Derivadal en lugar de 
heredar de Base. En este caso, la función imprimir 
seguiría siendo virtual y C++ sería capaz de selec- 
cionar la versión adecuada al llamar a dicha fun- 


Sobrecarga/sobreescrit. 


Cuando una función virtual se redefi- 
ne en una clase derivada, la función se 
sobreescribe. Para sobrecargar una fun- 
ción, recuerde que el número de pará- 
metros y/o sus tipos han de ser diferen- 
tes. 


ción. Si una clase derivada no sobreescribe una función virtual definida en la clase base, 


entonces se utiliza la versión de la clase base. 


El polimorfismo permite manejar la complejidad de los programas, garantizando la 
escalabilidad de los mismos, debido a que se basa en el principio de una interfaz, múlti- 
ples métodos. Por ejemplo, si un programa está bien diseñado, entonces se puede suponer 
que todos los objetos que derivan de una clase base se acceden de la misma forma, incluso 
si las acciones específicas varían de una clase derivada a la siguiente. Esto implica que 
sólo es necesario recordar una interfaz. Sin embargo, la clase derivada es libre de añadir 
uno o todos los aspectos funcionales especificados en la clase base. 
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Un aspecto clave para entender el polimorfismo reside en que la clase base y las 

LA derivadas forman una jerarquía, la cual plantea una evolución desde los aspectos 
más generales (clase base) hasta los aspectos más específicos (clases derivadas). Así, 
diseñar correctamente la clase base es esencial. 











Funciones virtuales puras y clases abstractas 


Si una función virtual no se redefine en la clase derivada, entonces se utiliza la fun- 
ción definida en la clase base. Sin embargo, en determinadas situaciones no tiene sentido 
definir una función virtual en una clase base debido a que semánticamente no es correc- 
to. El escenario típico se produce cuando existe una clase base, asociada a un concepto 
abstracto, para la que no pueden existir objetos. Por ejemplo, una clase Figura sólo tiene 
sentido como base de alguna clase derivada. 


En estos casos, es posible implementar las funciones virtuales de la clase base de 
manera que generen un error, ya que su ejecución carece de sentido en este tipo de clases 
que manejan conceptos abstractos. Sin embargo, C++ proporciona un mecanismo para 
tratar este tipo de situaciones: el uso de funciones virtuales puras. Este tipo de funciones 
virtuales permite la definición de clases abstractas, es decir, clases a partir de las cuales 
no es posible instanciar objetos. 


El siguiente listado de código muestra un ejemplo en el que se define la clase abstracta 
Figura, como base para la definición de figuras concretos, como el círculo. Note como la 
transformación de una función virtual en pura se consigue mediante el especificador =0. 


ttinclude <iostream> 
using namespace std; 


class Figura [ // Clase abstracta Figura. 


public: 
virtual float area () const = 0; // Función virtual pura. 
$»; 
class Circulo : public Figura f 
public: 
Circulo (float r): _radio(r) () 
void setRadio (float r) í _radio = r; ) 
float getRadio () const [ return _radio; ) 
// Redefinición de area () en Círculo. 
float area () const ( return _radio * _radio x* 3.14; ) 
private: 
float _radio; 
$; 


int main () 4 
Figura *f; 
Circulo c(1.0); 


f =8€c; 
cout << "AREA: " << f->area() << endl; 


// Recuerde realizar un casting al acceder a func. específica. 
cout << "Radio:" << static_cast<Circulox*>(f)->getRadio() << endl; 


return 0; 
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Fundamentos POO Recuerde que una clase con una o más funcio- 
pal ahy aloe nes virtuales puras es una clase abstracta y, por lo 
limorfimos representan los pilares fun- tanto, no se pueden realizar instancias a partir de 
damentales de la programación orien- ella. En realidad, la clase abstracta define una in- 
tada a objetos. terfaz que sirve como contrato funcional para el 


resto de clases que hereden a partir de la misma. 
En el ejemplo anterior, la clase Circulo está obligada a implementar la función area en 
caso de definirla. En caso contrario, el compilador generará un error. De hecho, si una 
función virtual pura no se define en una clase derivada, entonces dicha función virtual 
sigue siendo pura y, por lo tanto, la clase derivada es también una clase abstracta. 


El uso más relevante de las clases abstractas consiste en proporcionar una interfaz 
sin revelar ningún aspecto de la implementación subyacente. Esta idea está fuertemente 
relacionada con la encapsulación, otro de los conceptos fundamentales de la POO junto 
con la herencia y el polimorfismo. 


3.4. Plantillas 


En el desarrollo de software es bastante común encontrarse con situaciones en las 
que los programas implementados se parecen enormemente a otros implementados con 
anterioridad, salvo por la necesidad de tratar con distintos tipos de datos o de clases. Por 
ejemplo, un mismo algoritmo puede mantener el mismo comportamiento de manera que 
éste no se ve afectado por el tipo de datos a manejar. 


En esta sección se discute el uso de las plan- General y óptimo 
tillas en C++, un mecanismo que permite escribir oa cor deals 


código genérico sin tener dependencias explícitas juegos siempre existe un compromiso 
respecto a tipos de datos específicos. entre plantear una solución general y 


una solución optimizada para la plata- 
forma final. 


3.4.1. Caso de estudio. Listas 


En el ámbito del desarrollo de videojuegos, una 
de las principales estructuras de datos manejadas 
es la lista de elementos. Por ejemplo, puede existir una lista que almacene las distintas 
entidades de nuestro juego, otra lista que contenga la lista de mallas poligonales de un 
objeto o incluso es bastante común disponer de listas que almacenen los nombres de los 
jugadores en el modo multijugador. Debido a que existe una fuerte necesidad de manejar 
listas con distintos tipos de datos, es importante plantear una implementación que sea 
mantenible y práctica para tratar con esta problemática. 


Una posible alternativa consiste en que la propia clase que define los objetos conte- 
nidos en la lista actúe como propio nodo de la misma, es decir, que la propia clase sirva 
para implementar la lista (ver figura 3.3.a). Para ello, simplemente hay que mantener un 
enlace al siguiente elemento, o dos enlaces si se pretende construir una lista doblemente 
enlazada. El siguiente listado de código muestra un ejemplo de implementación. 


Aunque este planteamiento es muy sencillo y funciona correctamente, la realidad es 
que adolece de varios problemas: 


= Es propenso a errores de programación. El desarrollador ha de recordar casos parti- 
culares en la implementación, como por ejemplo la eliminación del último elemento 
de la lista. 


= Un cambio en la implementación de la clase previamente expuesta implicaría cam- 
biar un elevado número de clases. 
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= No es correcto suponer que todas las listas manejadas en nuestro programa van 
a tener la misma interfaz, es decir, la misma funcionalidad. Además, es bastante 
probable que un desarrollador utilice una nomenclatura distinta a la hora de imple- 
mentar dicha interfaz. 


class Entidad ( 
public: 
// Funcionalidad de la lista. 
Entidad * getSiguiente (); 
void eliminar (); 
void insertar (Entidad *pNuevo); 


private: 
// Puntero a la cabeza de la lista. 
Entidad *_pSiguiente; 

y; 


Otra posible solución consiste en hacer uso de la herencia para definir una clase ba- 
se que represente a cualquier elemento de una lista (ver figura 3.3.b). De este modo, 
cualquier clase que desee incluir la funcionalidad asociada a la lista simplemente ha de 
extenderla. Este planteamiento permite tratar a los elementos de la lista mediante poli- 
morfismo. Sin embargo, la mayor desventaja que presenta este enfoque está en el diseño, 
ya que no es posible separar la funcionalidad de la lista de la clase propiamente dicha, de 
manera que no es posible tener el objeto en múltiples listas o en alguna otra estructura de 
datos. Por lo tanto, es importante separar la propia lista de los elementos que realmente 
contiene. 


Una alternativa para proporcionar esta separación consiste en hacer uso de una lista 
que maneja punteros de tipo nulo para albergar distintos tipos de datos (ver figura 3.3.c). 
De este modo, y mediante los moldes correspondientes, es posible tener una lista con 
elementos de distinto tipo y, al mismo tiempo, la funcionalidad de la misma está separada 
del contenido. La principal desventaja de esta aproximación es que no es type-safe, es 
decir, depende del programador incluir la funcionalidad necesaria para convertir tipos, ya 
que el compilador no los detectará. 


Otra desventaja de esta propuesta es que son necesarias dos reservas de memoria para 
cada uno de los nodos de la lista: una para el objeto y otra para el siguiente nodo de 
la lista. Este tipo de cuestiones han de considerarse de manera especial en el desarrollo 
de videojuegos, ya que la plataforma hardware final puede tener ciertas restricciones de 
recursos. 


La figura 3.3 muestra de manera gráfica las distintas opciones discutidas hasta aho- 
ra en lo relativo a la implementación de una lista que permita el tratamiento de datos 
genéricos. 


3.4.2. Utilizando plantillas en C++ 


C++ proporciona el concepto de plantilla como solución a la implementación de có- 
digo genérico, es decir, código que no esté vinculado a ningún tipo de datos en particular. 
La idea principal reside en instanciar la plantilla para utilizarla con un tipo de datos en 
particular. Existen dos tipos principales de plantillas: 1) plantillas de clases y 11) plantillas 
de funciones. 


Las plantillas de clases permiten utilizar tipos de datos genéricos asociados a una 
clase, posibilitando posteriormente su instanciación con tipos específicos. El siguiente 
listado de código muestra un ejemplo muy sencillo. 
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Elemento 
Lista 








MiClase 





(b) 


(a) 


<MiClase> 






Elemento 
Lista 








<MiClase> 


> <MiClase> —» | 






Elemento 
Lista 


<MiClase> 





(c) 


Figura 3.3: Distintos enfoques para la implementación de una lista con elementos génericos. (a) Integración en 
la propia clase de dominio. (b) Uso de herencia. (c) Contenedor con elementos de tipo nulo. 


Listado 3.30: Implementación de un triángulo con plantilla 





*tinclude <iostream> 
using namespace std; 


class Triangle 4 
public: 


0 OUNAE 


9 Triangle () (+ 


10 T getV1 () const ([ return _vl; ) 
11 T getV2 () const [ return _v2; ) 
12 T getV3 () const [ return _v3; ) 


14 private: 
15 T_vl, -v2, -V3; 
16 ); 


18 class Vec2 4 
19 public: 


20 Vec2 (int x, int y): 


21 Vec2 () (y 


22 int getX () const [ return _x; ) 
23 int getY () const [ return _y; ) 


24 

25 private: 

26 int _x, y; 
27 y; 

28 

29 int main () £ 


30  Vec2 p1(2, 7), p2(3, 4), p3(7, 10); 


template<class T> // Tipo general T. 


Xx00), y) 0 


Triangle (const T 6v1, const T 6v2, const T 4v3): 
-v1(v1), -v2(v2), -v3(v3) (+ 


31 Triangle<Vec2> t(p1, p2, p3); // Instancia de la plantilla. 


32 


33 cout << "V1: [" << t.getV1().getX() << ", " 


34 << t.getV1().getY() << "]" << endl; 


35 return 0; 
36 ) 
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Como se puede apreciar, se ha definido una clase Triángulo que se puede utilizar 
para almacenar cualquier tipo de datos. En este ejemplo, se ha instanciado un triángulo 
con elementos del tipo Vec2, que representan valores en el espacio bidimensional. Para 
ello, se ha utilizado la palabra clave template para completar la definición de la clase 
Triángulo, permitiendo el manejo de tipos genéricos T. Note cómo este tipo genérico se 
usa para declarar las variables miembro de dicha clase. 


Clase Vec2 Las plantillas de funciones siguen la misma 
La dle ade pala ber idea que las plantillas de clases aplicándolas a las 
dido mediante el uso de plantillas pa- funciones. Obviamente, la principal diferencia con 
ra manejar otros tipos de datos comu- respecto a las plantillas a clases es que no necesitan 
nes a la representación de puntos en el instanciarse. El siguiente listado de código muestra 


espacio bidimensional, como por ejem- 


un ejemplo sencillo de la clásica función swap para 
plo valores en punto flotante. Smnp PP 


intercambiar el contenido de dos variables. 


Htinclude <iostream> 
using namespace std; 


template<class T> // Tipo general T. 
void swap (T 8a, T €b) 4 

T aux(a); 

a=b; 

b = aux; 


) 


int main () 4 
string a = "Hello", b = "Good-bye"; 
cout << "[" << a << ", "<< b << "]" << endl; 


swap(a, b); // Se instancia para cadenas. 


cout << "[" << a << 
return 0; 


) 


<< b << "]" << endl; 


Dicha función puede utilizarse con enteros, valores en punto flotante, cadenas o cual- 
quier clase con un constructor de copia y un constructor de asignación. Además, la función 
se instancia dependiendo del tipo de datos utilizado. Recuerde que no es posible utilizar 
dos tipos de datos distintos, es decir, por ejemplo un entero y un valor en punto flotante, 
ya que se producirá un error en tiempo de compilación. 


El uso de plantillas en C++ solventa todas las necesidades planteadas para manejar las 
listas introducidas en la sección 3.4.1, principalmente las siguientes: 


= Flexibilidad, para poder utilizar las listas con distintos tipos de datos. 


= Simplicidad, para evitar la copia de código cada vez que se utilice una estructura 
de lista. 


= Uniformidad, ya que se maneja una única interfaz para la lista. 


= Independencia, entre el código asociado a la funcionalidad de la lista y el código 
asociado al tipo de datos que contendrá la lista. 


A continuación se muestra la implementación de una posible solución, la cual está 
compuesta por dos clases generales. La primera de ellas se utilizará para los nodos de la 
lista y la segunda para especificar la funcionalidad de la propia lista. 


3.4. Plantillas 
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Uso de plantillas 


Las plantillas son una herramienta ex- 
celente para escribir código que no de- 
penda de un tipo de datos específico. 


template<class T> 

class NodoLista Y 

public: 
NodoLista (T datos); 
T € getDatos (); 
NodoLista * siguiente (); 


private: 
T _datos; 
$; 


template<class T> 

class Lista £ 

public: 
NodoLista<T> getCabeza (); 
void insertarFinal (T datos); 
// Resto funcionalidad... 


private: 
NodoLista<T> x_cabeza; 


y; 


Como se puede apreciar en el siguiente listado 
de código, las dos clases están definidas para poder 
utilizar cualquier tipo de dato y, además, la funcio- 
nalidad de la lista es totalmente independiente del 
su contenido. 


3.4.3. ¿Cuándo utilizar plantillas? 


Las plantillas de C++ representan un arma muy poderosa para implementar código 
génerico que se pueda utilizar con distintos tipos de datos. Sin embargo, al igual que ocu- 
rre con la herencia, hay que ser especialmente cuidadoso a la hora de utilizarlas, debido a 
que un uso inadecuado puede generar problemas y retrasos en el desarrollo de software. 
A continuación se enumeran las principales desventajas que plantea el uso de plantillas 


[3]: 


= Complejidad, debido a la integración de nueva nomenclatura que puede dificultar 
la legibilidad del código. Además, el uso de plantillas hace que la depuración de 
código sea más difícil. 


= Dependencia, ya que el código de la plantilla ha de incluirse en un fichero de cabe- 
cera para que sea visible por el compilador a la hora de instanciarlo. Este plantea- 
miento incrementa el acoplamiento entre clases. Además, el tiempo de compilación 
se ve afectado. 


= Duplicidad de código, debido a que si, por ejemplo, se crea una lista con un nuevo 
tipo de datos, el compilador ha de crear una nueva clase de lista. Es decir, todas las 
funciones y variables miembro se duplican. En el desarrollo de videojuegos, este 
inconveniente es generalmente asumible debido a la magnitud de los proyectos. 


= Soporte del compilador, ya que las plantillas no existen como una solución ple- 
namente estandarizada, por lo que es posible, aunque poco probable, que algunos 
compiladores no las soporten. 
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Desde una perspectiva general, no debe olvidar que las plantillas representan una he- 
rramienta adecuada para un determinado uso, por lo que su uso indiscriminado es un error. 
Recuerde también que las plantillas introducen una dependencia de uso respecto a otras 
clases y, por lo tanto, su diseño debería ser simple y mantenible. 


Una de las situaciones en las que el uso de plan- 


Equipo de desarrollo 


Es importante recordar la experiencia 
de los compañeros, actuales y futuros, 
en un grupo de desarrollo a la hora 
de introducir dependencias con aspec- 
tos avanzados en el uso de plantillas en 
C++. 


tillas resulta adecuado está asociada al uso de con- 
tenedores, es decir, estructuras de datos que contie- 
nen objetos de distintas clases. En este contexto, es 
importante destacar que la biblioteca STL de C++ 
ya proporciona una implementación de listas, ade- 


más de otras estructuras de datos y de algoritmos 
listos para utilizarse. Por lo tanto, es bastante probable que el desarrollador haga un uso 
directo de las mismas en lugar de tener que desarrollar desde cero su propia implemen- 
tación. En el capítulo 5 se estudia el uso de la biblioteca STL y se discute su uso en el 
ámbito del desarrollo de videojuegos. 


3.5. Manejo de excepciones 


A la hora de afrontar cualquier desarrollo software, un programador siempre tiene que 
tratar con los errores que dicho software puede generar. Existen diversas estrategias para 
afrontar este problema, desde simplemente ignorarlos hasta hacer uso de técnicas que los 
controlen de manera que sea posible recuperarse de los mismos. En esta sección se dis- 
cute el manejo de excepciones en C++ con el objetivo de escribir programas robustos 
que permitan gestionar de manera adecuada el tratamiento de errores y situaciones ines- 
peradas. Sin embargo, antes de profundizar en este aspecto se introducirán brevemente 
las distintas alternativas más relevantes a la hora de tratar con errores. 


3.5.1. Alternativas existentes 


La estrategia más simple relativa al tratamiento de errores consiste en ignorarlos. 
Aunque parezca una opción insensata y arriesgada, la realidad es que la mayoría de pro- 
gramas hacen uso de este planteamiento en una parte relevante de su código fuente. Este 
hecho se debe, principalmente, a que el programador asume que existen distintos tipos de 
errores que no se producirán nunca, o al menos que se producirán con una probabilidad 
muy baja. Por ejemplo, es bastante común encontrar la sentencia fclose sin ningún tipo de 
comprobación de errores, aún cuando la misma devuelve un valor entero indicando si se 
ha ejecutado correctamente o no. 


En el caso particular del desarrollo de video- 
juegos, hay que ser especialmente cuidadoso con 
determinadas situaciones que en otros dominios de 
aplicación pueden no ser tan críticas. Por ejemplo, 
no es correcto suponer que un PC tendrá memo- 
ria suficiente para ejecutar un juego, siendo nece- 
sario el tratamiento explícito de situaciones como 
una posible falta de memoria por parte del sistema. Desde otro punto de vista, el usuario 
que compra un videojuego profesional asume que éste nunca va a fallar de manera inde- 
pendiente a cualquier tipo de situación que se pueda producir en el juego, por lo que el 
desarrollador de videojuegos está obligado a considerar de manera especial el tratamiento 
de errores. 


A 
Aunque el desarrollo de videojuegos 
comerciales madura año a año, aún 
hoy en día es bastante común encontrar 
errores y bugs en los mismos. Algunos 
de ellos obligan incluso a resetear la 
estación de juegos por completo. 
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Tradicionalmente, uno de los enfoques más utilizados ha sido el retorno de códigos 
de error, típico en lenguajes de programación de sistemas como C. Desde un punto de 
vista general, este planteamiento se basa en devolver un código numérico de error, o al 
menos un valor booleano, indicando si una función se ejecutó correctamente o no. El 
código que realiza la llamada a la función es el responsable de recoger y tratar dicho valor 
de retorno. 


Este enfoque tiene su principal desventaja en el mantenimiento de código, motivado 
fundamentalmente por la necesidad de incluir bloques ¡f-then-else para capturar y gestio- 
nar los posibles errores que se puedan producir en un fragmento de código. Además, la 
inclusión de este tipo de bloques complica la legibilidad del código, dificultando el enten- 
dimiento y ocultando el objetivo real del mismo. Finalmente, el rendimiento del programa 
también se ve afectado debido a que cada llamada que realizamos ha de estar envuelta en 
una sentencia ¿f. 


Otra posible alternativa para afrontar el trata- 
miento de errores consiste en utilizar aserciones 


Constructores 
El uso de códigos de error presenta una 


(asserts), con el objetivo de parar la ejecución del dificultad añadida en el uso de cons- 
programa y evitar así una posible terminación abrup-  tructores, ya que estos no permiten la 
ta. Obviamente, en el desarrollo de videojuegos es- devolución de valores. En los destruc- 


ta alternativa no es aceptable, pero sí se puede uti- tores se da la misma situación, 


lizar en la fase de depuración para obtener la mayor cantidad de información posible (por 
ejemplo, la línea de código que produjo el error) ante una situación inesperada. 


Hasta ahora, los enfoques comentados tienen una serie de desventajas importantes. En 
este contexto, las excepciones se posicionan como una alternativa más adecuada y prác- 
tica. En esencia, el uso de excepciones permite que cuando un programa se tope con una 
situación inesperada se arroje una excepción. Este hecho tiene como consecuencia que el 
flujo de ejecución salte al bloque de captura de excepciones más cercano. Si dicho bloque 
no existe en la función en la que se arrojó la excepción, entonces el programa gestionará 
de manera adecuada la salida de dicha función (destruyendo los objetos vinculados) y 
saltará a la función padre con el objetivo de buscar un bloque de captura de excepciones. 


Este proceso se realiza recursivamente hasta encontrar dicho bloque o llegará a la 
función principal delegando en el código de manejo de errores por defecto, que típica- 
mente finalizará la ejecución del programa y mostrará información por la salida estándar 
o generará un fichero de log. 


Los bloques de tratamiento de excepciones ofrecen al desarrollador la flexibilidad 
de hacer lo que desee con el error, ya sea ignorarlo, tratar de recuperarse del mismo o 
simplemente informar sobre lo que ha ocurrido. Este planteamiento facilita enormemente 
la distinción entre distintos tipos de errores y, consecuentemente, su tratamiento. 





Recuerde que después de la ejecución de un bloque de captura de excepciones, la eje- 
uy cución del programa continuará a partir de este punto y no desde donde la excepción 
fue arrojada. 











Además de la mantenibilidad del código y de la flexibilidad del planteamiento, las 
excepciones permiten enviar más información sobre la naturaleza del error detectado a 
las capas de nivel superior. Por ejemplo, si se ha detectado un error al abrir un fichero, 
la interfaz gráfica sería capaz de especificar el fichero que generó el problema. Por el 
contrario, la utilización de códigos de error no permitiría manejar información más allá 
de la detección de un error de entrada/salida. 
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3.5.2. Excepciones en C++ 


El uso de excepciones en C++ es realmente sencillo y gira en torno a tres palabras 
clave: throw, catch y try. En resumen, cuando un fragmento de código necesita arrojar 
una excepción, entonces hace uso de throw. El control del programa pasa entonces al 
bloque de código de captura de excepciones más cercano, representado por la sentencia 
catch. Este bloque de captura está vinculado obligatoriamente a un bloque de código en 
el cual se podría lanzar la excepción, el cual está a su vez envuelto por una sentencia try. 


El siguiente listado de código muestra un ejem- 
plo muy sencillo de captura de excepciones (líneas 
(s-11)) ante la posibilidad de que el sistema no pue- 
da reservar memoria (líneas (6-8)). En este caso par- 
ticular, el programa captura una excepción defini- 
da en la biblioteca estándar de C++ denominada 
bad_alloc, de manera que se contempla un posi- 
ble lanzamiento de la misma cuando se utiliza el 
operador new para asignar memoria de manera di- 


ES A 
C++ maneja una jerarquía de excep- 
ciones estándar para tipos generales, 
como por ejemplo logic_error o run- 
time_error, O aspectos más específi- 
cos, como por ejemplo out_of_range O 
bad_alloc. Algunas de las funciones de 
la biblioteca estándar de C++ lanzan al- 
gunas de estas excepciones. 


námica. 


Htinclude <iostream> 
*tinclude <exception> 
using namespace std; 


int main () £ 


try £ 
int x*array = new int[1000000]; 


catch (bad_alloc de) Y 
cerr << "Error al reservar memoria. 


) 


<< endl; 


return 0; 


Como se ha comentado anteriormente, la sentencia throw se utiliza para arrojar ex- 
cepciones. C++ es estremadamente flexible y permite lanzar un objeto de cualquier tipo 
de datos como excepción. Este planteamiento posibilita la creación de excepciones defi- 
nidas por el usuario que modelen las distintas situaciones de error que se pueden dar en 
un programa e incluyan la información más relevante vinculadas a las mismas. 


El siguiente listado de código muestra un ejemplo de creación y tratamiento de excep- 
ciones definidas por el usuario. 


En particular, el código define una excepción general en las líneas mediante la 
definición de la clase MiExcepcion, que tiene como variable miembro una cadena de texto 
que se utilizará para indicar la razón de la excepción. En la función main, se lanza una 
instancia de dicha excepción, definida en la línea (21), cuando el usuario introduce un valor 
numérico que no esté en el rango [1, 10]. Posteriormente, dicha excepción se captura en 


las líneas (24-26). 


Normalmente, será necesario tratar con distin- 


Excepciones y clases h A E 
tos tipos de excepciones en un mismo programa. 


Las excepciones se modelan exacta- 


mente igual que cualquier otro tipo de 
objeto y la definición de clase puede 
contener tanto variables como funcio- 
nes miembro. 


Un enfoque bastante común consiste en hacer uso 
de una jerarquía de excepciones, con el mismo plan- 
teamiento usado en una jerarquía de clases, para 
modelar distintos tipos de excepciones específicas. 


30: 
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Listado 3.34: Excepción definida por el usuario 


1 *tinclude <iostream> 


2 
3 
4 


0 mu 


using namespace std; 


class MiExcepcion Y 
const string £_razon; 


public: 
MiExcepcion (const string $razon): _razon(razon) () 
const string $getRazon () const (return _razon;) 


y; 


int main () € 
int valor; 
const string €r = "Valor introducido incorrecto."; 


try [ 
cout << "Introduzca valor entre 1 y 10..."; 
cin >> valor; 


if ((valor < 1) || (valor > 10)) € 
throw MiExcepcion(r); 
) 
) 
catch (MiExcepcion e) f 
cerr << e.getRazon() << endl; 


, 


return 0; 


La figura 3.4 muestra un ejemplo representativo vinculado con el desarrollo de vi- 


deojuegos, en la que se plantea una jerarquía con una clase base y tres especializaciones 
asociadas a errores de gestión de memoria, E/S y operaciones matemáticas. 


MiExcepción 


MiExcepciónMemoria MiExcepciónIO MiExcepciónMatemática 





Figura 3.4: Ejemplo de jerarquía de excepciones. 
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Como se ha comentado anteriormente, los bloques de sentencias try-catch son real- 
mente flexibles y posibilitan la gestión de diversos tipos de excepciones. El siguiente 
listado de código muestra un ejemplo en el que se carga información tridimensional en 
una estructura de datos. 


La idea del siguiente fragmento de código se puede resumir en que el desarrollador 
está preocupado especialmente por la gestión de errores de entrada/salida o mátematicos 
(primer y segundo bloque catch, respectivamente) pero, al mismo tiempo, no desea que 
otro tipo de error se propague a capas superiores, al menos un error que esté definido en 
la jerarquía de excepciones (tercer bloque catch). Finalmente, si se desea que el programa 
capture cualquier tipo de excepción, entonces se puede añadir una captura genérica (ver 
cuarto bloque catch). En resumen, si se lanza una excepción no contemplada en un bloque 
catch, entonces el programa seguirá buscando el bloque catch más cercano. 


Listado 3.35: Gestión de múltiples excepciones 


1 void Mesh::cargar (const char *+archivo) ( 

2 try £ 

3 Stream stream(archivo); // Puede generar un error de 1/0. 
4 cargar(stream); 
5 
6 
7 
8 


catch (MiExcepcionI0 e) £ 
// Gestionar error 1/0. 
y 
9 catch (MiExcepcionMatematica € e) 4 
10 // Gestionar error matemático. 
11 
12 catch (MiExcepcion e) 


13 // Gestionar otro error... 

14 y 

15 catch (...) £ 

16 // Cualquier otro tipo de error... 
17 y 

18 ) 


Es importante resaltar que el orden de las sen- 


Exception handlers S ñ 
tencias catch es relevante, ya que dichas senten- 


El tratamiento de excepciones se pue- 


de enfocar con un esquema parecido cias siempre se procesan de arriba a abajo. Ade- 
al del tratamiento de eventos, es decir, más, cuando el programa encuentra un bloque que 
mediante un planteamiento basado en trata con la excepción lanzada, el resto de bloques 


capas y que delege las excepciones pa se ignoran automáticamente. 
ra su posterior gestión. 

Otro aspecto que permite C++ relativo al mane- 
jo de excepciones es la posibilidad de re-lanzar una excepción, con el objetivo de delegar 
en una capa superior el tratamiento de la misma. El siguiente listado de código muestra 


un ejemplo en el que se delega el tratamiento del error de entrada/salida. 
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void Mesh: :cargar (const char x*archivo) ( 


try ( 
Stream stream(archivo); // Puede generar un error de 1/0. 
cargar(stream); 


J 


catch (MiExcepcionl0 e) 
if (e.datosCorruptos()) £ 
// Tratar error 1/0. 
) 
else ( 
throw; // Se re-lanza la excepción. 
y 
) 


3.5.3. ¿Cómo manejar excepciones adecuadamente? 


Además de conocer cómo utilizar las sentencias relativas al tratamiento de excep- 
ciones, un desarrollador ha de conocer cómo utilizarlas de manera adecuada para evitar 
problemas potenciales, como por ejemplo no liberar memoria que fue reservada previa- 
mente al lanzamiento de una excepción. En términos generales, este problema se puede 
extrapolar a cómo liberar un recurso que se adquirió previamente a la generación de un 
error. 


El siguiente listado de código muestra cómo utilizar excepciones para liberar correcta- 
mente los recursos previamente reservados en una función relativa a la carga de texturas 
a partir de la ruta de una imagen. 


Como se puede apreciar, en la función cargarTextura se reserva memoria para el ma- 
nejador del archivo y para el propio objeto de tipo textura. Si se generase una excepción 
dentro del bloque try, entonces se ejecutaría el bloque catch genérico que se encarga de 
liberar los dos recursos previamente mencionados. Así mismo, todos los recursos locales 
de la propia función se destruirán tras salir de la misma. 


Sin embargo, este planteamiento se puede mejorar considerando especialmente la na- 
turaleza de los recursos manejados en la función, es decir, los propios punteros. El resto de 
recursos utilizados en la función tendrán sus destructores correctamente implementados 
y se puede suponer que finalizarán adecuadamente tras la salida de la función en caso de 
que se genere una excepción. La parte problemática está representada por los punteros, 
ya que no tienen asociado destructores. 


En el caso del manejador de archivos, una solu- 


A s d Smart pointers 
ción elegante consiste en construir un wrapper, es 


En C++ es bastante común utilizar he- 


decir, una clase que envuelva la funcionalidad de rramientas que permitan manejar los 
dicho manejador y que su constructor haga uso de punteros de una forma más cómodo. 
fopen mientras que su destructor haga uso de fclo- Un ejemplo representativo son los pun- 


se. Así, si se crea un objeto de ese tipo en la pila, eros inteligentes o smart pointers. 


el manejador del archivo se liberará cuando dicho 
objeto quede fuera de alcance (de la función). 
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Listado 3.37: Uso adecuado de excepciones 


Textura x* cargarTextura (const char xruta) 4 
FILE xentrada = NULL; 
Textura *pTextura = NULL; 


entrada = fopen(ruta, "rb"); 


1 
2 
3 
4 
5 try [ 
6 
7 // Instanciar recursos locales... 
8 
9 


pTextura = new Textura(/x*..., ...*/); 
leerTextura(entrada, pTextura); 
10 J 
11 catch (...) £ // Liberar memoria ante un error 
12 delete pTextura; 
13 pTexture = NULL; 
14 


15 

16 fclose(entrada); 
17 return pTextura; 
18 ) 


En el caso del puntero a la textura, es posible aplicar una solución más sencilla para 
todos los punteros: el uso de la plantilla unique_ptr. Dicha clase forma parte del estándar 
de 2011 de C++ y permite plantear un enfoque similar al del anterior manejador pero 
con punteros en lugar de con ficheros. Básicamente, cuando un objeto de dicha clase se 
destruye, entonces el puntero asociado también se libera correctamente. A continuación 
se muestra un listado de código con las dos soluciones discutidas. 


Listado 3.38: Uso adecuado de excepciones (simple) 


unique_ptr<Textura> cargarTextura (const char *ruta) 4 
FilePtr entrada(ruta, "rb"); 
// Instanciar recursos locales... 
unique _ptr<Textura> pTextura(new Textura(/*..., ...*/)); 


leerTextura(entrada, pTextura); 


1 
2 
3 
4 
5 
6 
7 return pTextura; 
8 


Como se puede apreciar, no es necesario incluir ningún tipo de código de manejo de 
excepciones, ya que la propia función se encarga de manera implícita gracias al enfoque 
planteado. Recuerde que una vez que el flujo del programa abandone la función, ya sea de 
manera normal o provocado por una excepción, todo los recursos habrán sido liberados 
de manera adecuada. 


Finalmente, es importante destacar que este tipo de punteros inteligentes se pueden 
utilizar en otro tipo de situaciones específicas, como por ejemplo los constructores. Re- 
cuerde que, si se genera una excepción en un constructor, no es posible devolver ningún 
código de error. Además, si ya se reservó memoria en el constructor, entonces se produ- 
cirá el clásico memory leak, es decir, la situación en la que no se libera una porción de 
memoria que fue previamente reservada. En estos casos, el destructor no se ejecuta ya 
que, después de todo, el constructor no finalizó correctamente su ejecución. La solución 
pasa por hacer uso de este tipo de punteros. 
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El caso de los destructores es menos problemático, ya que es lógico suponer que 
nadie hará uso de un objeto que se va a destruir, incluso cuando se genere una excepción 
dentro del propio destructor. Sin embargo, es importante recordar que el destructor no 
puede lanzar una excepción si el mismo fue llamado como consecuencia de otra excep- 
ción. 


3.5.4. ¿Cuándo utilizar excepciones? 


En el ámbito particular del tratamiento de excepciones en el desarrollo de videojuegos, 
las excepciones se deberían utilizar para modelar situaciones realmente excepcionales [3], 
es decir, situaciones que nunca ocurren o que ocurren con poquísima frecuencia. Cuando 
se lanza una excepción se pone en marcha un proceso complejo compuesto de diversas 
operaciones, como por ejemplo la búsqueda del bloque de manejo de excepciones más 
cercano, la modificación de la pila, la destrucción de objetos y la transferencia del control 
del programa al bloque catch. 


Este proceso es lento y afectaría enormemente al rendimiento del programa. Sin em- 
bargo, en el ámbito del desarrollo de videojuegos esta situación no resulta tan crítica, 
debido a que el uso de excepciones se limita, generalmente, a casos realmente excepcio- 
nales. En otras palabras, las excepciones no se utilizan para detectar que, por ejemplo, 
un enemigo ha caído al agua, sino para modelar aspectos críticos como que el sistema 
se esté quedando sin memoria física. Al final, este tipo de situaciones puede conducir a 
una eventual parada del sistema, por lo que el impacto de una excepción no resulta tan 
importante. 


En este contexto, las consolas de videojuegos — plataformas HW 
representan el caso más extremo, ya que normal- En el ámbra dl arde de 
mente tienen los recursos acotados y hay que ser juegos, el uso de excepciones está es- 
especialmente cuidadoso con el rendimiento de los trechamente con la plataforma HW fi- 
juegos. El caso más representativo es el tamaño de nal sobre la que se ejecutará el juego en 
la memoria principal, en el que el impacto de uti- Pues denia a Eee ende 
lizar excepciones puede ser desastroso. Sin embar- PO AI 
go, en un PC este problema no es tan crítico, por lo que el uso de excepciones puede ser 
más recomendable. Algunos autores recomiendan no hacer uso de excepciones [5], sino 
de códigos de error, en el desarrollo para consolas de videojuegos, debido a su limitada 
capacidad de memoria. 


También es importante reflexionar sobre el impacto del uso de las excepciones cuando 
no se lanzan, es decir, debido principalmente a la inclusión de sentencias try-catch. En 
general, este impacto está vinculado al compilador y a la forma que éste tiene para tratar 
con esta situación. Otro aspecto relevante es dónde se usa este tipo de sentencias. Si es 
en fases del juego como la carga inicial de recursos, por ejemplo mapas o modelos, se 
puede asumir perfectamente la degradación del rendimiento. Por el contrario, si dichas 
sentencias se van a ejecutar en un módulo que se ejecuta continuamente, entonces el 
rendimiento se verá afectado enormemente. 





En general, las excepciones deberían usarse en aquellas partes de código en las que 

y es posible que ocurra un error de manera inesperada. En el caso particular de los vi- 
deojuegos, algunos ejemplos representativos son la detección de un archivo corrupto, 
un fallo hardware o una desconexión de la red. 
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El uso de excepciones puede coexistir perfectamente con el uso de valores de retorno, 
aunque es importante tener claro cuándo utilizar un planteamiento y cuándo utilizar otro. 
Por ejemplo, en el ámbito del desarrollo de videojuegos, el uso de valores de retorno 
es una solución más práctica y limpia si lo que se desea es simplemente conocer si una 
función terminó su ejecución de manera adecuada o no, independientemente de los tipos 
de errores que puedan producirse. 





Capítulo 
Patrones de Diseño 





Cleto Martín Angelina 
Francisco Moya Fernández 


uando nos enfrentamos al diseño de un programa informático como un videojuego, 

no es posible abordarlo por completo desde una primera aproximación. El proceso 

de diseño de una aplicación suele ser iterativo y en diferentes etapas de forma que 

se vaya refinando con el tiempo. El diseño perfecto y a la primera es muy difícil de 
conseguir. 


La tarea de diseñar aplicaciones es compleja y, con seguridad, una de las más impor- 
tantes y que más impacto tiene no sólo sobre el producto final, sino también sobre su vida 
futura. En el diseño de la aplicación es donde se definen las estructuras y entidades que 
se van a encargar de resolver el problema modelado, así como sus relaciones y sus depen- 
dencias. Cómo de bien definamos estas entidades y relaciones influirá, en gran medida, 
en el éxito o fracaso del proyecto y en la viabilidad de su mantenimiento. 


El diseño, por tanto, es una tarea capital en el ciclo de vida del software. Sin embargo, 
no existe un procedimiento sistemático y claro sobre cómo crear el mejor diseño para un 
problema dado. Podemos utilizar metodologías, técnicas y herramientas que nos permitan 
refinar nuestro diseño. La experiencia también juega un papel importante. Sin embargo, 
el contexto de la aplicación es crucial y los requisitos, que pueden cambiar durante el 
proceso de desarrollo, también. 


Un videojuego es un programa con una componente muy creativa y artísticas. Ade- 
más, el mercado de videojuegos se mueve muy deprisa y la adaptación a ese medio cam- 
biante es un factor determinante. En general, los diseños de los programas deben ser 
escalables, extensibles y que permitan crear componentes reutilizables. 


Esta última característica es muy importante ya que la experiencia nos hace ver que 
al construir una aplicación se nos presentan situaciones recurrentes y que se asemejan 
a situaciones pasadas. Es el deja vú en el diseño: «¿cómo solucioné esto?». En esencia, 
muchos componentes pueden modelarse de formas similares. 

En este capítulo, se exploran las bases de los patrones de diseño que almacenan este 


conocimiento experimental procedente del estudio de aplicaciones, de los éxitos y fraca- 
sos de casos reales. Bien utilizados, permiten obtener un mejor diseño más temprano. 
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4.1. Introducción 


El diseño de una aplicación es un proceso iterativo y de continuo refinamiento. Nor- 
malmente, una aplicación es lo suficientemente compleja como para que su diseño tenga 
que ser realizado por etapas, de forma que al principio se identifican los módulos más 
abstractos y, progresivamente, se concreta cada módulo con un diseño en particular. 


En el camino, es común encontrar problemas y situaciones que conceptualmente pue- 
den parecerse entre sí, por lo menos a priori. Quizás un estudio más exhaustivo de los 
requisitos (o del contexto) permitan determinar si realmente se trata de problemas equi- 
valentes. 


Por ejemplo, supongamos que para resolver un determinado problema se llega a la 
conclusión de que varios tipos de objetos deben esperar a un evento producido por otro. 
Esta situación puede darse en la creación de una interfaz gráfica donde la pulsación de 
un botón dispara la ejecución de otras acciones. Pero también es similar a la implemen- 
tación de un manejador del teclado, cuyas pulsaciones son recogidas por los procesos 
interesados, o la de un gestor de colisiones, que notifica choques entre elementos del jue- 
go. Incluso se parece a la forma en que muchos programas de chat envían mensajes a un 
grupo de usuarios. 


Ciertamente, cada uno de los ejemplos anteriores tendrá una implementación diferente 
y no es posible (ni a veces deseable) aplicar exactamente la misma solución a cada uno de 
ellos. Sin embargo, sí que es cierto que existe semejanza en la esencia del problema. En 
nuestro ejemplo, en ambos casos existen entidades que necesitan ser notificadas cuando 
ocurre un cierto evento. Esa semejanza en la esencia del problema que une los diseños de 
dos soluciones tiene que verse reflejada, de alguna manera, en la implementación final. 


Los patrones de diseño son formas bien conocidas y probadas de resolver problemas 
de diseño que son recurrentes en el tiempo. Los patrones de diseño son ampliamente uti- 
lizados en las disciplinas creativas y técnicas. Así, de la misma forma que un guionista de 
cine crea guiones a partir de patrones argumentales como «comedia» o «ciencia-ficción», 
un ingeniero se basa en la experiencia de otros proyectos para identificar patrones comu- 
nes que le ayuden a diseñar nuevos procesos. De esta forma, reutilizando soluciones bien 
probadas y conocidas se ayuda a reducir el tiempo necesario para el diseño. 


Según [4], un patrón de diseño es una descripción de la comunicación entre objetos 
y clases personalizadas para solucionar un problema genérico de diseño bajo un contexto 
determinado. Los patrones sintetizan la tradición y experiencia profesional de diseñadores 
de software experimentados que han evaluado y demostrado que la solución proporciona- 
da es una buena solución bajo un determinado contexto. El diseñador o desarrollador que 
conozca diferentes patrones de diseño podrá reutilizar estas soluciones, pudiendo alcanzar 
un mejor diseño más rápidamente. 


4.1.1. Elementos básicos de diseño 


Si el lector alguna vez ha oído conceptos como Singleton o Decorator ya sabe, a 
grandes líneas, a qué nos referimos cuando hablamos de patrones de diseño. Sin embargo, 
estructuras básicas como un bucle for o un if no se consideran patrones de diseño, al 
menos a nivel de diseño que solemos referirnos. 


Los propios los lenguajes de programación de alto nivel que se utilizan en la mayo- 
ría de los programas permiten despreocuparnos sobre el diseño de estas estructuras de 
control simples. Obviamente para alguien que trabaje en bajo nivel, un bucle es un pa- 
trón de diseño que le permite modelar un programa complejo (en términos de bajo nivel). 
Claramente, el nivel de abstracción que utilicemos es clave en el diseño y definirá qué 
estructuras asumimos como básicas y cuáles no. 
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Object Method Field Type 
Object Is of type 
Method Method call Field Use Returns of ty- 
pe 
Field State change Cohesion Is of type 
Type Subtyping 


Tabla 4.1: Interacciones entre las entidades básicas de la POO (versión simplificada) [8] 


Para los lenguajes de alto nivel que ofrecen la posibilidad de trabajar con diseño orien- 
tado a objetos cabe preguntarse cuáles son las estructuras básicas con las que contamos. 
¿Cuáles son las relaciones mínimas entre estas entidades que podemos usar para el crear 
diseños? En general, ¿cuáles son las piezas atómicas del diseño? 


En [8] se da respuesta a estas preguntas. Basándose en el diseño orientado a objetos, 
se definen 4 entidades básicas fundamentales: 


= Tipos: normalmente clases, aunque es válido para lenguajes que no soportan clases. 
= Métodos: operaciones que se pueden realizar sobre un tipo. 
= Campos: que pueden ser variables o atributos. 


= Objetos: instancias de un tipo determinado y que tiene entidad por sí mismo. 


Si combinamos los 4 elementos anteriores unos con otros sistemáticamente y pen- 
samos en la relación que pueden tener se obtiene un resultado similar al mostrado en el 
cuadro 4.1. De forma simplificada y obviando algunas otras, aparecen las principales rela- 
ciones de dependencia entre las entidades. Por ejemplo, la relación object-type es aquella 
en la que una instancia depende de un tipo de determinado. Esta relación es cuando de- 
cimos que un objeto es de tipo X. field-method se produce cuando el valor devuelto por 
un método podemos llamarla cambio de estado. Todas estas relaciones y conceptos muy 
básicos y seguro que son de sobra conocidas. Sin embargo, resulta interesante estudiarlas 
por separado y como piezas básicas de un rompecabezas aún mayor que es el diseño de 
aplicaciones. 


La relación method-method es aquella en la que un método primero llama a otro como 
parte de su implementación. Esta simple relación nos permitirá definir patrones básicos 
de diseño como veremos más adelante. En este capítulo sólo nos centraremos en esta 
relación pero en [8] puede encontrarse un estudio detallado de las demás relaciones y 
consiguientes patrones de diseño elementales. 


4.1.2. Estructura de un patrón de diseño 


Cuando se describe un patrón de diseño se pueden citar más o menos propiedades del 
mismo: el problema que resuelve, sus ventajas, si proporciona escalabilidad en el diseño 
o no, etc. Nosotros vamos a seguir las directrices marcadas por los autores del famoso 
libro de Design Patterns [4] |, por lo que para definir un patrón de diseño es necesario 
describir, como mínimo, cuatro componentes fundamentales: 


= Nombre: el nombre del patrón es fundamental. Es deseable tener un nombre corto y 
autodefinido, de forma que sea fácil de manejar por diseñadores y desarrolladores. 





lTambién conocido como The Gang of Four (GoF) (la «Banda de los Cuatro») en referencia a los autores 
del mismo. Sin duda se trata de un famoso libro en este área, al que no le faltan detractores. 
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Los buenos nombres pueden ser compartidos por todos de forma que se cree un vo- 
cabulario común con el que se pueda describir documentación fácilmente, además 
de construir y detallar soluciones más complejas basadas en patrones. También se 
deben indicar los alias del patrón. 


= Problema y contexto: obviamente, el problema que resuelve un patrón en concreto 
debe ser descrito detalladamente. Sin embargo, es muy importante que se dé una 
definición clara del contexto en el que el patrón tiene sentido aplicarlo. El contexto 
se puede ver como un listado de precondiciones que deben ser cumplidas para poder 
aplicar el patrón. 


= Solución: la solución que proporciona un patrón se describe genéricamente y nunca 
ligada a ninguna implementación. Normalmente, se utiliza los conceptos y nomen- 
clatura de la programación orientada objetos. Por ello, la solución normalmente 
describe las clases y las relaciones entre objetos, así como la responsabilidad de 
cada entidad y cómo colaboran entre ellas para llegar a la solución. 


Gracias a la adopción de esta nomenclatura, la implementación de los patrones en 
los lenguajes orientados a objetos como C++ es más directa dada su especificación 
abstracta. 


= Ventajas y desventajas: la aplicación de un patrón de diseño no es una decisión 
que debe tomarse sin tener en cuenta los beneficios que aporta y sus posibles in- 
convenientes. Junto con los anteriores apartados, se deben especificar las ventajas 
y desventajas que supone la aplicación del patrón en diferentes términos: compleji- 
dad, tiempo de ejecución, acoplamiento, cohesión, extensibilidad, portabilidad, etc. 
Si estos términos están documentados, será más sencillo tomar una decisión. 





El uso de patrones de diseño es recomendable. Sin embargo, hay que tener en cuenta 
que un patrón no es bueno ni malo en sí mismo ni en su totalidad. El contexto de 

A aplicación puede ser determinante para no optar por una solución basada en un de- 
terminado patrón. Los cañones pueden ser una buena arma de guerra, pero no para 
matar moscas. 





4.1.3. Tipos de patrones 


De entre los diferentes criterios que se podrían adoptar para clasificar los diferentes 
patrones de diseño, uno de los más aceptados es el ámbito de diseño donde tienen aplica- 
ción. De esta forma, se definen las tres categorías clásicas: 


= Patrones de creación: se trata de aquellos que proporcionan una solución relaciona- 
da con la construcción de clases, objetos y otras estructuras de datos. Por ejemplo, 
patrones como Abstract Factory, Builder y otros ofrecen mecanismos de creación 
de instancias de objetos y estructuras escalables dependiendo de las necesidades. 


= Patrones estructurales: este tipo de patrones versan sobre la forma de organizar 
las jerarquías de clases, las relaciones y las diferentes composiciones entre objetos 
para obtener un buen diseño en base a unos requisitos de entrada. Patrones como 
Adapter, Facade o Flyweight son ejemplos de patrones estructurales. 


= Patrones de comportamiento: las soluciones de diseño que proporcionan los patro- 
nes de comportamiento están orientadas al envío de mensajes entre objetos y cómo 
organizar ejecuciones de diferentes métodos para conseguir realizar algún tipo de 
tarea de forma más conveniente. Algunos ejemplos son Visitor, Iterator y Observer. 


4.2. Patrones elementales [115] 








Algunos profesionales, como Jeff Atwood, critican el uso «excesivo» de patrones. 
Argumentan que es más importante identificar bien las responsabilidades de cada en- 

uy tidad que el propio uso del patrón. Otros se plantean si el problema no está realmente 
en los propios lenguajes de programación, que no proporcionan las herramientas se- 
mánticas necesarias. 











Como ya se introdujo en la sección 4.1.1, los patrones de diseño definidos en esas 
categorías pueden verse como patrones compuestos por otro más simples y atómicos. Por 
ello, a continuación se mencionan y describen algunos de los patrones elementales que 
son la base para la definición de patrones más complejos. 


4.2. Patrones elementales 


En esta sección se describen algunos (no todos) de los patrones elementales emergidos 
de la relación method-method, es decir, «cuando un método A llama desde su implemen- 
tación a un método B». Esta relación es transitiva, es decir, no importa lo largo que sea la 
cadena de invocaciones entre un método y otro para decir que el método A depende de B. 
Por ejemplo, en el siguiente fragmento de código a.x() depende de b.y(): 


class B ( 
void y() ( 
Was 
, 
F 


class A [ 
Bb; 
void x() £ 
by 0; 
los. 


F 
main () £ 


Aa; 
a.x(); 


Sin embargo, la relación anterior no cambiaría aunque en el método x() no se llamara 
directamente a b.y(), como ocurre en el siguiente fragmento de código: 
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class Bf 
void y() 1 
IR. 


) 


class Cf 
Bb; 
void z() £ 
b.y0O; 
y 
y 


class A [ 
Ce; 
void x() £ 
c.z(); 
IE is 


main () X 
Aa; 
a.x(); 


De igual forma, sigue habiendo una relación de dependencia entre a.x() y b.y(), esta 
vez por un camino más largo (y que podría introducir errores). Sin embargo, en esencia, 
existe un elemento básico común en el diseño de las dos aplicaciones anteriores y es esa 
relación entre los métodos. En estos ejemplos es muy evidente, pero ocurre con frecuencia 
en código de aplicaciones reales donde las relaciones de diseño son más simples de lo que 
a primera vista parece. 








Method Similar Method Dissimilar 
Object similar Recursion Conglomeration 
Object dissimilar Redirection Delegation 


Tabla 4.2: Patrones de diseño elementales en la relación method-method (versión simplificada) [8]. No se tiene 
en cuenta la tercera componente correspondiente al tipo 


Simplificando lo expuesto en detalle en [8], el cuadro 4.2. Simplemente atendiendo a 
la relación method-method y haciendo las combinaciones posibles entre los objetos y los 
métodos indicados, obtenemos 4 patrones de diseño elementales, es decir, atómicos: 


= Recursion: la recursión podemos definirla como la relación method-method en el 
que los objetos y los métodos implicados son los mismos. 


= Conglomeration: si los objetos son el mismo pero se invoca a un método dife- 
rente. Esto ocurre con bastante frecuencia dentro de una clase en la que diferentes 
métodos se invocan entre sí. 


= Redirection: una redirección se produce cuando un objeto recibe una invocación a 
un método y éste invoca «el mismo» método de otro objeto. Cuando se habla del 
«mismo» nos referimos a un método que «hace lo mismo» en términos de dise- 
ño aunque su implementación no sea exactamente la misma. Por ejemplo, la redi- 
rección es común en sistemas en donde el trabajo se divide en diferentes objetos 
(instancias) y un manager reparte el trabajo. 


4.2. Patrones elementales 1117] 





= Delegation: decimos que un método delega funcionalidad en otro cuando se invoca 
a un método diferente del mismo objeto. Un ejemplo típico son las clases que tienen 
referencias a objetos que hacen diferentes trabajos por ella. 


Los dos primeros patrones no necesitan mucha más explicación. Son ampliamente co- 


nocidos y utilizados. Sin embargo, para ver más claramente la diferencia entre Delegation 
y Redirection véase los siguientes fragmentos de código: 


Listado 4.3: Delegation (ejemplo) 


1 class WheelMaker £ 

2 Wheel makeWheel () 4 

3 // do the wheel and return it 
4 ) 

57 

6 

7 class CarMaker (£ 

8 WheelMaker w; 

9 Car makeCar() 4 

10 Wheel wheel1l = w.makeWheel (); 
11 /1/ ... do more stuff 

12 

13 ) 

14 

15 main() X 

16 WheelMaker w; 

17 w.makeCar(); 

18 ) 


El método print() es el mismo en términos del trabajo que hay que realizar de ca- 
ra al cliente, es decir, al usuario de PrinterManager. Ambos imprimen un documento y 
aunque están definidos en diferentes tipos, el diseño nos apunta a que el resultado es un 
documento impreso. Por ello, cuando un objeto invoca el «mismo» método de otro está 
redirigiendo su trabajo a otra instancia para que lo haga por él. 


Listado 4.4: Redirection(ejemplo) 


1 class Printer ( 

2 void print(Document d) Y 
3 leo.. 

4 ) 

5) 

6 

7 class PrinterManager 4 

8 Printer p; 

9 void print(Document d) Y 
10 p.print(d); 

11 lees 

12 

13 ) 

14 

15 main() £ 

16 Document d; 

17 PrinterManager m; 

18 m.print(d); 
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En este caso, claramente fabricar una rueda no es lo mismo que fabricar un coche. 
Por ello, los métodos makewheel () y makeCar() son completamente diferentes, por lo que 
no se puede hablar de una redirección de CarMaker en WheelMaker sino más bien de una 
delegación. El fabricante de un coche no puede tener todo el conocimiento necesario 
para crear cada componente del mismo. Sabe crear coches a partir de unas piezas básicas 
(ruedas, tornillos, etc.) pero no sabe fabricar las piezas. Por ello, delega funcionalidad en 
otros. 


Esto son solo 4 patrones elementales que se deducen a partir de la relación existente 
entre dos métodos. Todos los patrones que vienen a continuación se pueden expresar 
como una combinación de patrones elementales. Para ver la colección completa y cómo 
diseccionar patrones de alto nivel en componentes elementales se recomienda la lectura 
de [8]. 


4.3. Patrones de creación 


En esta sección se describen algunos patrones que ayudan en el diseño de problemas 
en los que la creación de instancias de diferentes tipos es el principal problema. 


4.3.1. Singleton 


El patrón singleton se suele utilizar cuando se requiere tener una única instancia de 
un determinado tipo de objeto. 


Problema 


En C++, utilizando el operador new es posible crear 
una instancia de un objeto. Sin embargo, es posible que 
necesitemos que sólo exista una instancia de una clase de- 
terminada por diferentes motivos (prevención de errores, 


+instance(): static Singleton : 
PotetantO seguridad, etc.). 





El balón en un juego de fútbol o la entidad que repre- 
senta al mundo 3D son ejemplos donde podría ser conve- 
niente mantener una única instancia de este tipo de obje- 
tos. 


Figura 4.1: Diagrama de clases del 
patrón Singleton. 


Solución 


Para garantizar que sólo existe una instancia de una clase es necesario que los clientes 
no puedan acceder directamente al constructor. Por ello, en un singleton el constructor es, 
por lo menos, protected. A cambio se debe proporcionar un único punto (controlado) por 
el cual se pide la instancia única. El diagrama de clases de este patrón se muestra en la 
figura 4.1. 
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Implementación 


A continuación, se muestra una implementación básica del patrón Singleton: 


/* Header */ 
class Ball ( 
protected: 


float _x, -y; 
static Ball* theBall_; 


Ball (float x, float y) : -x(x), -y(y) £ ); 
Ball(const Ballé£ ball); 
void operator=(const Ballá ball ) ; 


public: 
static Ball£ getTheBall (); 


void move(float _x, float _y) ([ /*...*/ ); 
y; 


Ballg£ Ball: :getTheBall () 
1 
static Ball theBall_; 
return theBall_; 
) 


Como se puede ver, la característica más importante es que los métodos que pueden 
crear una instancia de Ball son todos privados para los clientes externos. Todos ellos 
deben utilizar el método estático getTheBal1() para obtener la única instancia. Esta im- 
plementación no es válida para programas multihilo, es decir, no es thread-safe. 


Como ejercicio se plantea la siguiente pregunta: en la implementación proporcionada, 
¿Se garantiza que no hay memory leak? ¿Qué sería necesario para que la implementación 
fuera thread-safe? 


Consideraciones 


El patrón Singleton puede ser utilizado para modelar: 


= Gestores de acceso a base de datos, sistemas de ficheros, render de gráficos, etc. 


= Estructuras que representan la configuración del programa para que sea accesible 
por todos los elementos en cualquier instante. 


El Singleton es un caso particular de un patrón de diseño más general llamado Object 
Pool, que permite crear n instancias de objetos de forma controlada. 





La idoneidad del patrón Singleton es muy controvertida y está muy cuestionada. 
Muchos autores y desarrolladores, entre los que destaca Eric Gamma (uno de los 

YN autores de [4]) consideran que es un antipatrón, es decir, una mala solución a un 
problema de diseño. 
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4.3.2. Abstract Factory 


El patrón Abstract Factory permite crear diferentes tipos de instancias, aislando al 
cliente sobre cómo se debe crear cada una de ellas. 


Problema 


Conforme un programa crece, el número de clases que representan los diferentes tipos 
de objetos suele también crecer. Muchos de los diseños tienen jerarquías de objetos tales 
como la que se muestra en la figura 4.2. 










Weapon 


+shot() 
+reload() 


A 









+shot() 
+reload() 


+shot() 
+reload() 





Figura 4.2: Ejemplos de jerarquías de clases 


En ella, se muestra jerarquías de clases que modelan los diferentes tipos de personajes 
de un juego y algunas de sus armas. Para construir cada tipo de personaje es necesario 
saber cómo construirlo y con qué otro tipo de objetos tiene relación. Por ejemplo, restric- 
ciones del tipo «la gente del pueblo no puede llevar armas» o «los arqueros sólo pueden 
puede tener un arco», es conocimiento específico de la clase que se está construyendo. 


Supongamos que en nuestro juego, queremos obtener razas de personajes: hombres y 
orcos. Cada raza tiene una serie de características propias que hacen que pueda moverse 
más rápido, trabajar más o tener más resistencia a los ataques. 


El patrón Abstract Factory puede ser de ayuda en este tipo de situaciones en las que es 
necesario crear diferentes tipos de objetos utilizando una jerarquía de componentes. Dada 
la complejidad que puede llegar a tener la creación de una instancia es deseable aislar la 
forma en que se construye cada clase de objeto. 


Solución 


En la figura 4.3 se muestra la aplicación del patrón para crear las diferentes razas de 
soldados. Por simplicidad, sólo se ha aplicado a esta parte de la jerarquía de personajes. 


En primer lugar se define una factoría abstracta que será la que utilice el cliente (Game) 
para crear los diferentes objetos. CharFactory es una factoría que sólo define métodos 
abstractos y que serán implementados por sus clases hijas. Estas son factorías concretas 
a cada tipo de raza (ManFactory y OrcFactory) y ellas son las que crean las instancias 
concretas de objetos Archer y Rider para cada una de las razas. 
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En definitiva, el patrón Abstract Factory recomienda crear las siguientes entidades: 


= Factoría abstracta que defina una interfaz para que los clientes puedan crear los 
distintos tipos de objetos. 


= Factorías concretas que realmente crean las instancias finales. 


Implementación 


Basándonos en el ejemplo anterior, el objeto Game sería el encargado de crear los di- 
ferentes personajes utilizando una factoría abstracta. El siguiente fragmento de código 
muestra cómo la clase Game recibe una factoría concreta (utilizando polimorfismo) y la 
implementación del método que crea los soldados. 


Listado 4.6: Abstract Factory (Game) 


1 /x... */ 

2 Game game; 

3 SoldierFactoryx factory; 

4 

5 df (isSelectedMan) £ 

6 factory = new ManFactory(); 
7 Jj else 

8 factory = new OrcFactory(); 
9 7, 
10 
11 game->createSoldiers(factory); 
12 /x ... *x/ 
13 
14 


15 /* Game implementation */ 

16 vector<Soldier*> Game: :createSoldiers(SoldierFactoryx* factory) 
17 ( 

18 vector<Soliderx*> soldiers; 

19 for (int i=0; i<5; i++) 4 


20 soldiers.push_back(factory->makeArcher()); 
21 soldiers.push_back(factory->makeRider()); 
22 , 

23 return soldiers; 

24 ) 


Como puede observarse, la clase Game simplemente invoca los métodos de la factoría 
abstracta. Por ello, createSoldier() funciona exactamente igual para cualquier tipo de 
factoría concreta (de hombres o de orcos). 
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Una implementación del método makeArcher() de cada factoría concreta podría ser 
como sigue: 


/* OrcFactory */ 

Archerx OrcFactory::makeArcher ( 

t 
Archer archer = new Archer(); 
archer->setLife(200); 
archer->setName('0rc”); 
return archer; 


) 


/* ManFactory x*/ 

Archerx ManFactory::makeArcher ( 

t 
Archer archer = new Archer(); 
archer->setLife(100); 
archer->setName('Man”); 
return archer; 


Nótese como las factorías concretas ocultan las particularidades de cada tipo. Una 
implementación similar tendría el método makeRider(). 


Consideraciones 


El patrón Abstract Factory puede ser aplicable cuando: 
= el sistema de creación de instancias debe aislarse. 


= es necesaria la creación de varias instancias de objetos para tener el sistema confi- 
gurado. 


= la creación de las instancias implican la imposición de restricciones y otras particu- 
laridades propias de los objetos que se construyen. 


= los productos que se deben fabricar en las factorías no cambian excesivamente en 
el tiempo. Añadir nuevos productos implica añadir métodos a todas las factorías 
ya creadas, por lo que no es un patrón escalable y que se adapte bien al cambio. 
En nuestro ejemplo, si quisiéramos añadir un nuevo tipo de soldado deberíamos 
modificar la factoría abstracta y las concretas. Por ello, es recomendable que se 
aplique este patrón sobre diseños con un cierto grado de estabilidad. 


Un patrón muy similar a éste es el patrón Builder. Con una estructura similar, el patrón 
Builder se centra en el proceso de cómo se crean las instancias y no en la jerarquía de 
factorías que lo hacen posible. Como ejercicio se plantea estudiar el patrón Builder y 
encontrar las diferencias. 


4.3.3. Factory Method 


El patrón Factory Method se basa en la definición de una interfaz para crear instancias 
de objetos y permite a las subclases decidir cómo se crean dichas instancias implemen- 
tando un método determinado. 
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Figura 4.3: Aplicación del patrón Abstract Factory 


Problema 


Al igual que ocurre con el patrón Abstract Factory, el problema que se pretende re- 
solver es la creación de diferentes instancias de objetos abstrayendo la forma en que 
realmente se crean. 


Solución 


La figura 4.4 muestra un diagrama de clases para nuestro ejemplo que emplea el patrón 
Factory Method para crear ciudades en las que habitan personajes de diferentes razas. 


Como puede verse, los objetos de tipo Village tienen un método populate() que es 
implementado por las subclases. Este método es el que crea las instancias de Villager 
correspondientes a cada raza. Este método es el método factoría. Además de este méto- 
do, también se proporcionan otros como population() que devuelve la población total, o 
location() que devuelve la posición de la cuidad en el mapa. Todos estos métodos son 
comunes y heredados por las ciudades de hombres y orcos. 


Finalmente, objetos Game podrían crear ciudades y, consecuentemente, crear ciudada- 
nos de distintos tipos de una forma transparente. 


Consideraciones 


Este patrón presenta las siguientes características: 


= No es necesario tener una factoría o una jerarquía de factorías para la creación de 
objetos. Permite diseños más adaptados a la realidad. 
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Figura 4.4: Ejemplo de aplicación de Factory Mehod 


= El método factoría, al estar integrado en una clase, hace posible conectar dos jerar- 
quía de objetos distintas. Por ejemplo, si los personajes tienen un método factoría 
de las armas que pueden utilizar, el dominio de las armas y los personajes queda 
unido a través el método. Las subclases de los personajes crearían las instancias de 
Weapon correspondientes. 


Nótese que el patrón Factory Method se utiliza para implementar el patrón Abstract 
Factory ya que la factoría abstracta define una interfaz con métodos de construcción de 
objetos que son implementados por las subclases. 


4.3.4. Prototype 


El patrón Prototype proporciona abstracción a la hora de crear diferentes objetos en un 
contexto donde se desconoce cuántos y cuáles deben ser creados a priori. La idea principal 
es que los objetos deben poder clonarse en tiempo de ejecución. 


Problema 


Los patrones Factory Method y Abstract Factory tienen el problema de que se basan 
en la herencia e implementación de métodos abstractos por subclases para definir cómo se 
construye cada producto concreto. Para sistemas donde el número de productos concretos 
puede ser elevado o indeterminado esto puede ser un problema. 


Supongamos que en nuestra jerarquía de armas, cuya clase padre es Weapon, comienza 
a crecer con nuevos tipos de armas y, además, pensamos en dejar libertad para que se 
carguen en tiempo de ejecución nuevas armas que se implementarán como librerías diná- 
micas. Además, el número de armas variará dependiendo de ciertas condiciones del juego 
y de configuración. En este contexto, puede ser más que dudoso el uso de factorías. 
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Solución 


Para atender a las nuevas necesidades dinámicas en la creación de los distintos tipo 
de armas, sin perder la abstracción sobre la creación misma, se puede utilizar el patrón 
Prototype como se muestra en la figura 4.5. 
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Figura 4.5: Ejemplo de aplicación de Prototype 


La diferencia fundamental se encuentra en la adición del método clone() a todas los 
productos que pueden ser creados. El cliente del prototipo sólo tiene que invocar clone() 
sobre su instancia Weapon para que se cree una instancia concreta. Como se puede ver, no 
es necesario un agente intermedio (factorías) para crear instancias de un determinado tipo. 
La creación se realiza en la clase concreta que representa a la instancia, por lo que basta 
con cambiar la instancia prototype de Client para que se creen nuevos tipos de objetos en 
tiempo de ejecución. 


Consideraciones 


Algunas notas interesantes sobre Prototype: 


= Puede parecer que entra en conflicto con Abstract Factory debido a que intenta 
eliminar, precisamente, factorías intermedias. Sin embargo, es posible utilizar am- 
bas aproximaciones en una Prototype Abstract Factory de forma que la factoría se 
configura con los prototipos concretos que puede crear y ésta sólo invoca a clone(). 


= También es posible utilizar un gestor de prototipos que permita cargar y descargar 
los prototipos disponibles en tiempo de ejecución. Este gestor es interesante para 
tener diseños ampliables en tiempo de ejecución (plugins). 


= Para que los objetos puedan devolver una copia de sí mismo es necesario que en su 
implementación esté el constructor de copia (copy constructor) que en C++ viene 
por defecto implementado (aunque la implementación por defecto puede ser no 
adecuada). 


4.4. Patrones estructurales 


Hasta ahora, hemos visto patrones para diseñar aplicaciones donde el problema prin- 
cipal es la creación de diferentes instancias de clases. En esta sección se mostrarán los 
patrones de diseño estructurales que se centran en las relaciones entre clases y en cómo 
organizarlas para obtener un diseño eficiente para resolver un determinado problema. 
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4.4.1. Composite 


El patrón Composite se utiliza para crear una organización arbórea y homogénea de 
instancias de objetos. 


Problema 


Para ilustrar el problema supóngase un juego de estrategia en el que los jugadores 
pueden recoger objetos o items, los cuales tienen una serie de propiedades como «precio», 
«descripción», etc. Cada item, a su vez, puede contener otros items. Por ejemplo, un bolso 
de cuero puede contener una pequeña caja de madera que, a su vez, contiene un pequeño 
reloj dorado. 


En definitiva, el patrón Composite habla sobre cómo diseñar este tipo de estructuras 
recursivas donde la composición homogénea de objetos recuerda a una estructura arbórea. 


Solución 


Para el ejemplo expuesto anteriormente, la aplicación del patrón Composite quedaría 
como se muestran en la figura 4.6. Como se puede ver, todos los elementos son Items que 
implementan una serie de métodos comunes. En la jerarquía existen objetos compues- 
tos, COMO Bag, que mantienen una lista (items) donde residen los objetos que contiene. 
Naturalmente, los objetos compuestos suelen ofrecer también operaciones para añadir, 
eliminar y actualizar. Por otro lado, hay objetos hoja que no contienen a más objetos, 
como es el caso de Clock. 


+value() 
+description() 
A 


+value() +value() 
+description() +description() 


Figura 4.6: Ejemplo de aplicación del patrón Composite 





Consideraciones 
Al utilizar este patrón, se debe tener en cuenta las siguientes consideraciones: 


= Una buena estrategia para identificar la situación en la que aplicar este patrón es 
cuando tengo «un X y tiene varios objetos X». 


= La estructura generada es muy flexible siempre y cuando no importe el tipo de ob- 
jetos que pueden tener los objetos compuestos. Es posible que sea deseable prohibir 
la composición de un tipo de objeto con otro. Por ejemplo, un jarrón grande den- 
tro de una pequeña bolsa. La comprobación debe hacerse en tiempo de ejecución 
y no es posible utilizar el sistema de tipos del compilador. En este sentido, usando 
Composite se relajan las restricciones de composición entre objetos. 
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= Los usuarios de la jerarquía se hacen más sencillos, ya que sólo tratan con un tipo 
abstracto de objeto, dándole homogeneidad a la forma en que se maneja la estruc- 
tura. 


4.4.2. Decorator 


También conocido como Wrapper, el patrón Decorator sirve para añadir y/o modificar 
la responsabilidad, funcionalidad o propiedades de un objeto en tiempo de ejecución. 


Problema 


Supongamos que el personaje de nuestro videojuego porta un arma que utiliza para 
eliminar a sus enemigos. Dicha arma, por ser de un tipo determinado, tiene una serie de 
propiedades como el radio de acción, nivel de ruido, número de balas que puede almace- 
nar, etc. Sin embargo, es posible que el personaje incorpore elementos al arma que puedan 
cambiar estas propiedades como un silenciador o un cargador extra. 


El patrón Decorator permite organizar el diseño de forma que la incorporación de 
nueva funcionalidad en tiempo de ejecución a un objeto sea transparente desde el punto 
de vista del usuario de la clase decorada. 


Solución 


En la figura 4.7 se muestra la aplicación del patrón Decorator al supuesto anterior- 
mente descrito. Básicamente, los diferentes tipos de armas de fuego implementan una 
clase abstracta llamada Firearm. Una de sus hijas es FirearmDecorator que es el padre 
de todos los componentes que «decoran» a un objeto Firearm. Nótese que este decorador 
implementa la interfaz propuesta por Firearm y está compuesta por un objeto gun, el cual 
decora. 


Implementación 


A continuación, se expone una implementación en C++ del ejemplo del patrón Deco- 
rator. En el ejemplo, un arma de tipo Rifle es decorada para tener tanto silenciador como 
una nueva carga de munición. Nótese cómo se utiliza la instancia gun a lo largo de los 
constructores de cada decorador. 
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Listado 4.8: Decorator 


class Firearm 4 

public: 

virtual float noise() const 
virtual int bullets() const 





mon 
oo 


class Rifle : public Firearm f 

public: 

float noise () const ( return 150.0; ) 
10 int bullets () const [ return 5; ) 

11 ); 


1 
2 
3 
4 
5) 
6 
7 
8 
9 


13 /x* Decorators */ 


15 class FirearmDecorator : public Firearm ( 

16 protected: 

17 Firearmx _gun; 

18 public: 

19 FirearmDecorator(Firearm* gun): _gun(gun) 4); 

20 virtual float noise () const [ return _gun->noise(); ) 
21 virtual int bullets () const [ return _gun->bullets(); ) 
22 y; 

23 

24 class Silencer : public FirearmDecorator ( 

25 public: 

26 Silencer(Firearm* gun) : FirearmDecorator(gun) (7; 
27 float noise () const [ return _gun->noise() - 55; $ 
28 int bullets () const [ return _gun->bullets(); ) 
29 y; 

30 

31 class Magazine : public FirearmDecorator f 

32 public: 

33 Magazine(Firearm* gun) : FirearmDecorator(gun) 4); 
34 float noise () const [ return _gun->noise(); y 

35 int bullets () const [ return _gun->bullets() + 5; ) 
36 y; 

37 

38 /x* Using decorators */ 

39 

40 ... 

41 Firearm* gun = new Rifle(); 

42 cout << "Noise: " << gun->noise() << endl; 

43 cout << "Bullets: " << gun->bullets() << endl; 

44 ... 

45 // char gets a silencer 

46 gun = new Silencer(gun); 

47 cout << "Noise: " << gun->noise() << endl; 

48 cout << "Bullets: " << gun->bullets() << endl; 

49 ... 

50 // char gets a new magazine 

51 gun = new Magazine(gun)'; 

52 cout << "Noise: " << gun->noise() << endl; 

53 cout << "Bullets: " << gun->bullets() << endl; 


En cada momento, ¿qué valores se imprimen?. Supón que el personaje puede quitar 
el silenciador. ¿Qué cambios habría que hacer en el código para «quitar» el decorador a 
la instancia? 
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Consideraciones 


A la hora de aplicar el patrón Decorator se deben tener en cuenta las siguientes consi- 
deraciones: 


= Es un patrón similar al Composite. Sin embargo, existen grandes diferencias: 


e Está más centrado en la extensión de la funcionalidad que en la composición 
de objetos para la generación de una jerarquía como ocurre en el Composite. 


e Normalmente, sólo existe un objeto decorado y no un vector de objetos (aun- 
que también es posible). 


= Este patrón permite tener una jerarquía de clases compuestas, formando una es- 
tructura más dinámica y flexible que la herencia estática. El diseño equivalente 
utilizando mecanismos de herencia debería considerar todos los posibles casos en 
las clases hijas. En nuestro ejemplo, habría 4 clases: rifle, rifle con silenciador, rifle 
con cargador extra y rifle con silenciador y cargador. Sin duda, este esquema es 
muy poco flexible. 
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Figura 4.7: Ejemplo de aplicación del patrón Decorator 





4.4.3. Facade 


El patrón Facade eleva el nivel de abstracción de un determinado sistema para ocultar 
ciertos detalles de implementación y hacer más sencillo su uso. 


Problema 


Muchos de los sistemas que proporcionan la capacidad de escribir texto en pantalla 
son complejos de utilizar. Su complejidad reside en su naturaleza generalista, es decir, 
están diseñados para abarcar un gran número de tipos de aplicaciones. Por ello, el usuario 
normalmente debe considerar cuestiones de «bajo nivel» como es configurar el propio 
sistema interconectando diferentes objetos entre sí que, a priori, parece que nada tienen 
que ver con la tarea que se tiene que realizar. 
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Para ver el problema que supone para un usuario un bajo nivel de abstracción no 
es necesario recurrir a una librería o sistema externo. Nuestro propio proyecto, si está 
bien diseñado, estará dividido en subsistemas que proporcionan una cierta funcionalidad. 
Basta con que sean genéricos y reutilizables para que su complejidad aumente considera- 
blemente y, por ello, su uso sea cada vez más tedioso. 


Por ejemplo, supongamos que hemos creado diferentes sistemas para realizar distintas 
operaciones gráficas (manejador de archivos, cargador de imágenes, etc.). El siguiente 
código correspondería con la animación de una explosión en un punto determinado de la 
pantalla. 


Listado 4.9: Ejemplo de uso de diferentes subsistemas 


1 Filex file expl1 = FileManager::load_file("explosion1.tif"); 

2 Filex* file_exp2 = FileManager::load_file("explosion2.tif"); 

3 Imagex explosionl = ImageManager::get_image_from_file(file_exp1); 
4 Imagex* explosion2 = ImageManager: :get_image_from_file(file_exp2); 
5 Screen* screen = Screen: :get_screen(); 
6 
7 
8 
9 


screen->add_element(explosionl, x, y); 
screen->add_element(explosion2, x+2, y+2); 


10 /x* more configuration x/ 
11 ... 
12 screen->draw(); 


Sin duda alguna, y pese a que ya se tienen objetos que abstraen subsistemas tales co- 
mo sistemas de archivos, para los clientes que únicamente quieran mostrar explosiones 
no proporciona un nivel de abstracción suficiente. Si esta operación se realiza frecuente- 
mente, el código se repetirá a lo largo y ancho de la aplicación y problema se agrava. 


Solución 


Utilizando el patrón Facade, se proporciona un mayor nivel de abstracción al cliente 
de forma que se construye una clase «fachada» entre él y los subsistemas con menos 
nivel de abstracción. De esta forma, se proporciona una visión unificada del conjunto y, 
además, se controla el uso de cada componente. 


Para el ejemplo anterior, se podría crear una clase que proporcione la una funcionali- 
dad más abstracta. Por ejemplo, algo parecido a lo siguiente:: 


Listado 4.10: Simplificación utilizando Facade 


1 AnimationManager* animation = new AnimationManager(); 
2 animation->explosion_at(3,4); 


Como se puede ver, el usuario ya no tiene que conocer las relaciones que existen entre 
los diferentes módulos para crear este tipo de animaciones. Esto aumenta, levemente, el 
nivel de abstracción y hace más sencillo su uso. 


En definitiva, el uso del patrón Facade proporciona una estructura de diseño como la 
mostrada en la figura 4.8. 
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Figura 4.8: Ejemplo de aplicación del patrón Facade 


Consideraciones 
El patrón Facade puede ser útil cuando: 


= Es necesario refactorizar, es decir, extraer funcionalidad común de los sistemas y 
agruparla en función de las necesidades. 


= Los sistemas deben ser independientes y portables. 
= Se required controlar el acceso y la forma en que se utiliza un sistema determinado. 


= Los clientes pueden seguir utilizando los subsistemas directamente, sin pasar por la 
fachada, lo que da la flexibilidad de elegir entre una implementación de bajo nivel 
o no. 


Sin embargo, utilizando el patrón Facade es posible caer en los siguientes errores: 


= Crear clases con un tamaño desproporcionado. Las clases fachada pueden contener 
demasiada funcionalidad si no se divide bien las responsabilidades y se tiene claro 
el objetivo para el cual se creo la fachada. Para evitarlo, es necesario ser crítico/a 
con el nivel de abstracción que se proporciona. 


= Obtener diseños poco flexibles y con mucha contención. A veces, es posible crear 
fachadas que obliguen a los usuarios a un uso demasiado rígido de la funcionalidad 
que proporciona y que puede hacer que sea más cómodo, a la larga, utilizar los sub- 
sistemas directamente. Además, una fachada puede convertirse en un único punto 
de fallo, sobre todo en sistemas distribuidos en red. 


= Exponer demasiados elementos y, en definitiva, no proporcionar un nivel de abs- 
tracción adecuado. 


4.4.4. MVC 


El patrón MVC (Model View Controller) se utiliza para aislar el dominio de aplica- 
ción, es decir, la lógica, de la parte de presentación (interfaz de usuario). 
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Problema 


Programas como los videojuegos requieren la interacción de un usuario que, normal- 
mente, realiza diferentes acciones sobre una interfaz gráfica. Las interfaces disponibles 
son muy variadas: desde aplicaciones de escritorio con un entorno GTK (GIMP ToolKit) 
a aplicaciones web, pasando por una interfaz en 3D creada para un juego determinado. 


Supongamos que una aplicación debe soportar varios tipos de interfaz a la vez. Por 
ejemplo, un juego que puede ser utilizado con una aplicación de escritorio y, también, a 
través de una página web. El patrón MVC sirve para aislar la lógica de la aplicación, de la 
forma en que se ésta se presenta, su interfaz gráfica. 


Solución 


En el patrón MVC, mostrado en la figura 4.9, existen tres entidades bien definidas: 


= Vista: se trata de la interfaz de usuario que interactúa con el usuario y recibe sus 
órdenes (pulsar un botón, introducir texto, etc.). También recibe órdenes desde el 
controlador, para mostrar información o realizar un cambio en la interfaz. 


= Controlador: el controlador recibe órdenes utilizando, habitualmente, manejadores 
o callbacks y traduce esa acción al dominio del modelo de la aplicación. La acción 
puede ser crear una nueva instancia de un objeto determinado, actualizar estados, 
pedir operaciones al modelo, etc. 


= Modelo: el modelo de la aplicación recibe las acciones a realizar por el usuario, 
pero ya independientes del tipo de interfaz utilizado porque se utilizan, únicamente, 
estructuras propias del dominio del modelo y llamadas desde el controlador. 


Normalmente, la mayoría de las acciones que realiza el controlador sobre el modelo 
son operaciones de consulta de su estado para que pueda ser convenientemente 
representado por la vista. 





MVC no es patrón con una separación tan rígida. Es posible encontrar implemen- 
taciones en las que, por ejemplo, el modelo notifique directamente a las interfaces 
de forma asíncrona eventos producidos en sus estructuras y que deben ser repre- 
sentados en la vista (siempre y cuando exista una aceptable independencia entre las 
capas). Para ello, es de gran utilidad el patrón Observer (ver sección 4.5.1). 


Consideraciones 


El patrón MVC es la filosofía que se utiliza en un gran 
número de entornos de ventanas. Sin embargo, muchos 
sistemas web como Django también se basan en este pa- 
trón. Sin duda, la división del código en estos roles pro- 
porciona flexibilidad a la hora de crear diferentes tipos de 
E presentaciones para un mismo dominio. 





Controller 


Figura 49: Estuco del parón De hecho, desde un punto de vista general, la estruc- 

MVC. tura más utilizada en los videojuegos se asemeja a un pa- 
trón MVC: la interfaz gráfica utilizando gráficos 3D/2D 

(vista), bucle de eventos (controlador) y las estructuras de datos internas (modelo). 


4.4. Patrones estructurales [133] 





4.4.5. Adapter 


El patrón Adapter se utiliza para proporcionar una interfaz que, por un lado, cumpla 
con las demandas de los clientes y, por otra, haga compatible otra interfaz que, a priori, 
no lo es. 


Problema 


Es muy probable que conforme avanza la construcción de la aplicación, el diseño de 
las interfaces que ofrecen los componentes pueden no ser las adecuadas o, al menos, las 
esperadas por los usuarios de los mismos. Una solución rápida y directa es adaptar dichas 
interfaces a nuestras necesidades. Sin embargo, esto puede que no sea tan sencillo. 


En primer lugar, es posible que no tengamos la posibilidad de modificar el código de 
la clase o sistema que pretendemos cambiar. Por otro lado, puede ser que sea un requisito 
no funcional por parte del cliente: determinado sistema o biblioteca debe utilizarse sí o 
sí. Si se trata de una biblioteca externa (third party), puede ocurrir que la modificación 
suponga un coste adicional para el proyecto ya que tendría que ser mantenida por el propio 
proyecto y adaptar las mejoras y cambios que se añadan en la versión no modificada. 
Contando, claro, con que la licencia de la biblioteca permita todo esto. 


Por lo tanto, es posible llegar a la conclusión de que a pesar de que el sistema, biblio- 
teca o clase no se adapta perfectamente a nuestras necesidades, trae más a cuenta utilizarla 
que hacerse una versión propia. 


Solución 


Usando el patrón Adapter es posible crear una nueva interfaz de acceso a un determi- 
nado objeto, por lo que proporciona un mecanismo de adaptación entre las demandas del 
objeto cliente y el objeto servidor que proporciona la funcionalidad. 








Target 


A 


Adapter | adaptee 


IN 
adaptee->otherMethod() 


Figura 4.10: Diagrama de clases del patrón Adapter 









OtherSystem 
+otherMethod () 










En la figura 4.10 se muestra un diagrama de clases genérico del patrón basado en la 
composición. Como puede verse, el cliente no utiliza el sistema adaptado, sino el adapta- 
dor. Este es el que transforma la invocación a method() en otherMethod(). Es posible que 
el adaptador también incluya nueva funcionalidad. Algunas de las más comunes son: 


= La comprobación de la corrección de los parámetros. 
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= La transformación de los parámetros para ser compatibles con el sistema adaptado. 


Consideraciones 
Algunas consideraciones sobre el uso del patrón Adapter: 


= Tener sistemas muy reutilizables puede hacer que sus interfaces no puedan ser com- 
patibles con una común. El patrón Adapter es una buena opción en este caso. 


= Un mismo adaptador puede utilizarse con varios sistemas. 


= Otra versión del patrón es que la clase Adapter sea una subclase del sistema adap- 
tado. En este caso, la clase Adapter y la adaptada tienen una relación más estrecha 
que si se realiza por composición. 


= Este patrón se parece mucho al Decorator. Sin embargo, difieren en que la finalidad 
de éste es proporcionar una interfaz completa del objeto adaptador, mientras que el 
decorador puede centrarse sólo en una parte. 


4.4.6. Proxy 


El patrón Proxy proporciona mecanismos de abstracción y control para acceder a un 
determinado objeto «simulando» que se trata del objeto real. 


Problema 


Muchos de los objetos de los que puede constar una aplicación pueden presentar di- 
ferentes problemas a la hora de ser utilizados por clientes: 


= Coste computacional: es posible que un objeto, como una imagen, sea costoso de 
manipular y cargar. 


= Acceso remoto: el acceso por red es una componente cada vez más común entre las 
aplicaciones actuales. Para acceder a servidores remotos, los clientes deben conocer 
las interioridades y pormenores de la red (sockets, protocolos, etc.). 


= Acceso seguro: es posible que muchos objetos necesiten diferentes privilegios para 
poder ser utilizados. Por ejemplo, los clientes deben estar autorizados para poder 
acceder a ciertos métodos. 


= Dobles de prueba: a la hora de diseñar y probar el código, puede ser útil utilizar 
objetos dobles que reemplacen instancias reales que pueden hacer que las pruebas 
sea pesadas y/o lentas. 


Solución 


Supongamos el problema de mostrar una imagen cuya carga es costosa en términos 
computacionales. La idea detrás del patrón Proxy (ver figura 4.11) es crear una un objeto 
intermedio (ImageProxy) que representa al objeto real (Image) y que se utiliza de la misma 
forma desde el punto de vista del cliente. De esta forma, el objeto proxy puede cargar una 
única vez la imagen y mostrarla tantas veces como el cliente lo solicite. 
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+display() +display() 


Figura 4.11: Ejemplo de aplicación del patrón Proxy 

















Implementación 


A continuación, se muestra una implementación del problema anteriormente descrito 
donde se utiliza el patrón Proxy. En el ejemplo puede verse (en la parte del cliente) cómo 
la imagen sólo se carga una vez: la primera vez que se invoca a display(). El resto de 
invocaciones sólo muestran la imagen ya cargada. 


. . .Z 


Listado 4.11: Ejemplo de implementación de Proxy 


class Graphic £ 
public: 
void display() = 0; 


1 

2 

3 

4 y; 
5 

6 class Image : public Graphic 4 

7 public: 

8 void load() £ 

9 a 

10 /* perform a hard file load x*/ 
11 A 

12 J 

13 

14 void display() f 

15 e 

16 /* perform display operation */ 
17 

18 J 

19 ); 


21 class ImageProxy : public Graphic (f 
22 private: 
23 Imagex _image; 


24 public: 

25 void display() f 

26 if (not _image) f 
27 _image = new Image(); 
28 _image.load(); 
29 J 

30 _image->display(); 
31 J 

32 y; 

33 

34 /x* Client */ 

35 


36 Graphic image = new ImageProxy(); 
37 image->display(); // loading and display 
38 image->display(); // just display 
39 image->display(); // just display 
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Consideraciones 


Existen muchos ejemplos donde se hace un uso intensivo del patrón proxy en diferen- 
tes sistemas: 


= En los sistemas de autenticación, dependiendo de las credenciales presentadas por 
el cliente, devuelven un proxy u otro que permiten realizar más o menos operacio- 
nes. 


= En middlewares orientados a objetos como CORBA o ZeroC ICE (Internet Commu- 
nication Engine), se utiliza la abstracción del Proxy para proporcionar invocaciones 
remotas entre objetos distribuidos. Desde el punto de vista del cliente, la invocación 
se produce como si el objeto estuviera accesible localmente. El proxy es el encar- 
gado de proporcionar esta abstracción. 


4.5. Patrones de comportamiento 


Los patrones de diseño relacionados con el comportamiento de las aplicaciones se 
centran en cómo diseñar los sistemas para obtener una cierta funcionalidad y, al mismo 
tiempo, un diseño escalable. 


4.5.1. Observer 


El patrón Observer se utiliza para definir relaciones 1 a n de forma que un objeto 
pueda notificar y/o actualizar el estado de otros automáticamente. 


Problema 


Tal y como se describió en la sección 4.4.4, el dominio de la aplicación en el patrón 
MVC puede notificar de cambios a las diferentes vistas. Es importante que el dominio no 
conozca los tipos concretos de las vistas, de forma que haya que modificar el dominio en 
caso de añadir o quitar una vista. 


Otros ejemplos donde se da este tipo de problemas ocurren cuando el estado un ele- 
mento tiene influencia directa sobre otros. Por ejemplo, si en el juego se lanza un misil 
seguramente haya que notificar que se ha producido el lanzamiento a diferentes siste- 
mas como el de sonido, partículas, luz, etc. Además, otros objetos alredor pueden estar 
«interesados» en esta información. 


Solución 


El patrón Observer proporciona un diseño con poco acoplamiento entre los observa- 
dores y el objeto observado. Siguiendo la filosofía de publicación/suscripción, los objetos 
observadores se deben registrar en el objeto observado, también conocido como subject. 
Así, cuando ocurra el evento oportuno, el subject recibirá una invocación a través de 
notify() y será el encargado de «notificar» a todos los elementos suscritos a él a través 
del método update(). Los observadores que reciben la invocación pueden realizar las ac- 
ciones pertinentes como consultar el estado del dominio para obtener nuevos valores. En 
la figura 4.12 se muestra un esquema general del patrón Observer. 
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AS 
for ob in observers: 
ob->update() 









Subject 


+attach() 
+detach() 
+notify() 
















observers e 
z Observer 


A 

















ConcreteSubject 
+state() 


ConcreteObserver 





A 
return the_state 


NA 
subject->state() 


Figura 4.12: Diagrama de clases del patrón Observer 


A modo de ejemplo, en la figura 4.13 se muestra un diagrama de secuencia en el que 
se describe el orden de las invocaciones en un sistema que utiliza el patrón Observer. 
Nótese que los observadores se suscriben al subject (RocketLauncher) y, a continuación, 
reciben las actualizaciones. También pueden dejar de recibirlas, utilizando la operación 
detach(). 
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Figura 4.13: Diagrama de secuencia de ejemplo utilizando un Observer 


Consideraciones 


Al emplear el patrón Observer en nuestros diseños, se deben tener en cuenta las si- 
guientes consideraciones: 
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= El objeto subject puede encapsular funcionalidad compleja semánticamente que 
será notificada asíncronamente a los observadores. El objeto observable, puede de- 
finir diferentes estrategias a la hora de notificar un cambio. 


= Subject y sus observadores forman un modelo push/pull, por lo que evita la creación 
de protocolos de comunicación concretos entre ellos. Toda comunicación de este 
tipo pueden realizarse de la misma forma. 


= No es necesario que el subject sea el que realiza la llamada a notify(). Un cliente 
externo puede ser el que fuerce dicha llamada. 


= Los observadores pueden estar suscritos a más de un subject. 


= Los observadores no tienen control sobre las actualizaciones no deseadas. Es posi- 
ble que un observador no esté interesado en ciertas notificaciones y que sea necesa- 
rio consultar al Subject por su estado en demasiadas ocasiones. Esto puede ser un 
problema en determinados escenarios. 


Los canales de eventos es un patrón más genérico que el Observer pero que sigue 
respetando el modelo push/pull. Consiste en definir estructuras que permiten la comuni- 
cación n a n a través de un medio de comunicación (canal) que se puede multiplexar en 
diferentes temas (topics). Un objeto puede establecer un rol suscriptor de un tema dentro 
de un canal y sólo recibir las notificaciones de un único o varios topics. Además, también 
puede configurarse como publicador, por lo que podría enviar actualizaciones al mismo 
canal. 


4.5.2. State 


El patrón State es útil para realizar transiciones de estado e implementar autómatas 
respetando el principio de encapsulación. 


Problema 


Es muy común que en cualquier aplicación, incluido los videojuegos, existan estructu- 
ras que pueden ser modeladas directamente como un autómata, es decir, una colección de 
estados y unas transiciones dependientes de una entrada. En este caso, la entrada pueden 
ser invocaciones y/o eventos recibidos. 


Por ejemplo, los estados de un personaje de un videojuego podrían ser: «de pie», 
«tumbado», «andando» y «saltando». Dependiendo del estado en el que se encuentre y 
de la invocación recibida, el siguiente estado será uno u otro. Por ejemplo, si está de pie 
y recibe la orden de tumbarse, ésta se podrá realizar. Sin embargo, si ya está tumbado 
no tiene sentido volver a tumbarse, por lo que debe permanecer en ese estado. Tampoco 
podría no tener sentido pasar al estado de «saltando» directamente desde «tumbado» sin 
pasar antes por «de pie». 


Solución 


El patrón State permite encapsular el mecanismo de las transiciones que sufre un 
objeto a partir de los estímulos externos. En la figura 4.14 se muestra un ejemplo de 
aplicación del mismo. La idea es crear una clase abstracta que representa al estado del 
personaje (CharacterState). En ella se definen las mismas operaciones que puede recibir 
el personaje con una implementación por defecto. En este caso, la implementación es 
vacía. 
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AS 
Default implementation 
is "do nothing". 



















CharacterState 


AS 
state->jump(this) 





CharacterStanding 


+walk() 
+getDown () 
+jump (O) 





Automatic after a while: 
char->setState(CharacterStanding()) 





| 


char->setState(CharacterJumping()) 


Figura 4.14: Ejemplo de aplicación del patrón State 


Por cada estado en el que puede encontrarse el personaje, se crea una clase que he- 
reda de la clase abstracta anterior, de forma que en cada una de ellas se implementen los 
métodos que producen cambio de estado. 


Por ejemplo, según el diagrama, en el estado «de pie» se puede recibir la orden de ca- 
minar, tumbarse y saltar, pero no de levantarse. En caso de recibir esta última, se ejecutará 
la implementación por defecto, es decir, no hacer nada. 


En definitiva, la idea es que las clases que representan a los estados sean las encar- 
gadas de cambiar el estado del personaje, de forma que los cambios de estados quedan 
encapsulados y delegados al estado correspondiente. 


Consideraciones 


= Los componentes del diseño que se comporten como autómatas son buenos candi- 
datos a ser modelados con el patrón State. Una conexión TCP (Transport Control 
Protocol) o un carrito en una tienda web son ejemplos de este tipo de problemas. 


= Es posible que una entrada provoque una situación de error estando en un deter- 
minado estado. Para ello, es posible utilizar las excepciones para notificar dicho 
error. 


= Las clases que representan a los estados no deben mantener un estado intrínseco, 
es decir, no se debe hacer uso de variables que dependan de un contexto. De esta 
forma, el estado puede compartirse entre varias instancias. La idea de compartir un 
estado que no depende del contexto es la base fundamental del patrón Flyweight, 
que sirve para las situaciones en las que crear muchas instancias puede ser un pro- 
blema de rendimiento. 


4.5.3. Iterator 


El patrón Iterator se utiliza para ofrecer una interfaz de acceso secuencial a una de- 
terminada estructura ocultando la representación interna y la forma en que realmente se 
accede. 
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IN 
return new Concretelterator(this); 


Figura 4.15: Diagrama de clases del patrón Iterator 
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Problema 


Manejar colecciones de datos es algo muy habitual en el desarrollo de aplicaciones. 
Listas, pilas y, sobre todo, árboles son ejemplos de estructuras de datos muy presentes en 
los juegos y se utilizan de forma intensiva. 


Una operación muy frecuente es recorrer las estructuras para analizar y/o buscar los 
datos que contienen. Es posible que sea necesario recorrer la estructura de forma secuen- 
cial, de dos en dos o, simplemente, de forma aleatoria. Los clientes suelen implementar 
el método concreto con el que desean recorrer la estructura por lo que puede ser un pro- 
blema si, por ejemplo, se desea recorrer una misma estructura de datos de varias formas 
distintas. Conforme aumenta las combinaciones entre los tipos de estructuras y métodos 
de acceso, el problema se agrava. 


Solución 


Con ayuda del patrón Iterator es posible obtener acceso secuencial, desde el punto de 
vista del usuario, a cualquier estructura de datos, independientemente de su implemen- 
tación interna. En la figura 4.15 se muestra un diagrama de clases genérico del patrón. 
Como puede verse, la estructura de datos es la encargada de crear el iterador adecuado 
para ser accedida a través del método iterator(). Una vez que el cliente ha obtenido el 
iterador, puede utilizar los métodos de acceso que ofrecen tales como next () (para obtener 
el siguiente elemento) o isDone() para comprobar si no existen más elementos. 


Implementación 


A continuación, se muestra una implementación simplificada y aplicada a una estruc- 
tura de datos de tipo lista. Nótese cómo utilizando las primitivas que ofrece la estructura, 
el iterador proporciona una visión de acceso secuencial a través del método next (). 
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Listado 4.12: Iterator (ejemplo) 


1 class List : public Struct 4 
2 public: 
3 void add(const Objecté ob) [ /x add element in a list*/ ); 





4 void remove(const Objecté ob) [ /* remove element in a list*/ P; 
5 Object get_at(const int index) ([ /* get list[index] elementx*/ ); 
6 

7 /x* more access methods x*/ 

8 

9 void iterator(const Objecté ob) f 

10 return new Listlterator(this); 

11 F; 

12 ); 

13 


14 class Listlterator : public Iterator ( 
15 private: 

16 int _currentIndex; 

17 List _list; 


18 

19 public: 

20 ListIterator (Listx* list) : _currentIndex(0), _list(list) ( P; 
21 

22 Object next() £ 

23 if (isDone()) £ 

24 throw new Iterator0utOfBounds(); 

25 J 

26 Object retval = _list->get_at(_currentIndex); 
27 _currentIndex++; 

28 return retval; 

29 F; 

30 

31 Object first() 4 

32 return _list->get_at(0); 

33 $ 

34 

35 bool isDone() X 

36 return _currentIndex > _list->length(); 
37 F; 

38 ); 

39 

40 /* client using iterator */ 

41 


42 List list = new List(); 
43 ListlIterator it = list.iterator(); 


45 for (Object ob = it.first(); not it.isDone(); it.next()) € 
46 // do the loop using 'ob” 
47 y; 


Consideraciones 


La ventaja fundamental de utilizar el patrón Iterator es la simplificación de los clientes 
que acceden a las diferentes estructuras de datos. El control sobre el acceso lo realiza el 
propio iterador y, además, almacena todo el estado del acceso del cliente. De esta forma 
se crea un nivel de abstracción para los clientes que acceden siempre de la misma forma 
a cualquier estructura de datos con iteradores. 


Obviamente, nuevos tipos de estructuras de datos requieren nuevos iteradores. Sin em- 
bargo, para añadir nuevos tipos de iteradores a estructuras ya existentes puede realizarse 
de dos formas: 
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= Añadir un método virtual en la clase padre de todas las estructuras de forma que 
los clientes puedan crear el nuevo tipo iterador. Esto puede tener un gran impacto 
porque puede haber estructuras que no se pueda o no se desee acceder con el nuevo 
Iterador. 


= Añadir un nuevo tipo de estructura que sea dependiente del nuevo tipo del itera- 
dor. Por ejemplo, RandomizedList que devolvería un iterador RandomIterator y que 
accede de forma aleatoria a todos los elementos. 





(5) La STL de C++ implementa el patrón Iterator en todos los contenedores que ofrece. 











4.5.4. Template Method 


El patrón Template Method se puede utilizar cuando es necesario redefinir algunos 
pasos de un determinado algoritmo utilizando herencia. 


Problema 


En un buen diseño los algoritmos complejos se dividen en funciones más pequeñas, de 
forma que si se llama a dichas funciones en un determinado orden se consigue implemen- 
tar el algoritmo completo. Conforme se diseña cada paso concreto, se suele ir detectando 
funcionalidad común con otros algoritmos. 


Por ejemplo, supongamos que tenemos dos tipos de jugadores de juegos de mesa: 
ajedrez y damas. En esencia, ambos juegan igual; lo que varía son las reglas del juego 
que, obviamente, condiciona su estrategia y su forma de jugar concreta. Sin embargo, en 
ambos juegos, los jugadores mueven en su turno, esperan al rival y esto se repite hasta 
que acaba la partida. 


El patrón Template Method consiste extraer este comportamiento común en una clase 
padre y definir en las clases hijas la funcionalidad concreta. 


Solución 


Siguiendo con el ejemplo de los jugadores de ajedrez y damas, la figura 4.16 muestra 
una posible aplicación del patrón Template Method a modo de ejemplo. Nótese que la 
clase GamePlayer es la que implementa el método play() que es el que invoca a los otros 
métodos que son implementados por las clases hijas. Este método es el método plantilla. 


Cada tipo de jugador define los métodos en base a las reglas y heurísticas de su juego. 
Por ejemplo, el método isOver() indica si el jugador ya no puede seguir jugando porque 
se ha terminado el juego. En caso de las damas, el juego se acaba para el jugador si se ha 
quedado sin fichas; mientras que en el caso ajedrez puede ocurrir por jaque mate (además 
de otros motivos). 


Consideraciones 
Algunas consideraciones sobre el patrón Template Method: 


= Utilizando este patrón se suele obtener estructuras altamente reutilizables. 
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if moveFirst(): 
doBestMove(); 


GamePlayer 


+play () while !isOver(): 
+doBestMove() waitForOpponent(); 
+isOver() if (!isOver()); 
+moveFirst() doBestMove(); 






ChessPlayer 


+doBestMove ( ) 
+isOver() 
+moveFirst() 


CheckersPlayer 


+doBestMove () 
+isOver() 
+moveFirst() 


IN NS 
return isCheckmate(); return noMoreChecker(); 


Figura 4.16: Aplicación de ejemplo del patrón Template Method 






= Introduce el concepto de operaciones hook que, en caso de no estar implementadas 
en las clases hijas, tienen una implementación por defecto. Las clases hijas pueden 
sobreescribirlas para añadir su propia funcionalidad. 


4.5.5. Strategy 


El patrón Strategy se utiliza para encapsular el funcionamiento de una familia de al- 
goritmos, de forma que se pueda intercambiar su uso sin necesidad de modificar a los 
clientes. 


Problema 


En muchas ocasiones, se suele proporcionar diferentes algoritmos para realizar una 
misma tarea. Por ejemplo, el nivel de habilidad de un jugador viene determinado por 
diferentes algoritmos y heurísticas que determinan el grado de dificultad. Utilizando di- 
ferentes tipos algoritmos podemos obtener desde jugadores que realizan movimientos 
aleatorios hasta aquellos que pueden tener cierta inteligencia y que se basan en técnicas 
de IA. 


Lo deseable sería poder tener jugadores de ambos tipos y que, desde el punto de vista 
del cliente, no fueran tipos distintos de jugadores. Simplemente se comportan diferente 
porque usan distintos algoritmos internamente, pero todos ellos son jugadores. 


Solución 


Mediante el uso de la herencia, el patrón Strategy permite encapsular diferentes al- 
goritmos para que los clientes puedan utilizarlos de forma transparente. En la figura 4.17 
puede verse la aplicación de este patrón al ejemplo anterior de los jugadores. 
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GamePlayer | strategy | Movement | 
+doBestMove () +move (context) 


DN 
strategy->move(context); 


























RandomMovement 


+move (context) 


Figura 4.17: Aplicación de ejemplo del patrón Strategy 


lAMovement 


+move(context) 


La idea es extraer los métodos que conforman el comportamiento que puede ser in- 
tercambiado y encapsularlo en una familia de algoritmos. En este caso, el movimiento 
del jugador se extrae para formar una jerarquía de diferentes movimientos (Movement). 
Todos ellos implementan el método move() que recibe un contexto que incluye toda la 
información necesaria para llevar a cabo el algoritmo. 


El siguiente fragmento de código indica cómo se usa este esquema por parte de un 
cliente. Nótese que al configurarse cada jugador, ambos son del mismo tipo de cara al 
cliente aunque ambos se comportarán de forma diferente al invocar al método doBestMove(). 


GamePlayer bad_player = new GamePlayer(new RandomMovement ()); 
GamePlayer good_player = new GamePlayer(new IAMovement()); 


bad_player->doBestMove(); 
good_player->doBestMove(); 


Consideraciones 


El patrón Strategy es una buena alternativa a realizar subclases en las entidades que 
deben comportarse de forma diferente en función del algoritmo utilizado. Al extraer la 
heurística a una familia de algoritmos externos, obtenemos los siguientes beneficios: 


= Se aumenta la reutilización de dichos algoritmos. 
= Se evitan sentencias condicionales para elegir el comportamiento deseado. 


= Los clientes pueden elegir diferentes implementaciones para un mismo compor- 
tamiento deseado, por lo que es útil para depuración y pruebas donde se pueden 
escoger implementaciones más simples y rápidas. 


4.5.6. Reactor 


El patrón Reactor es un patrón arquitectural para resolver el problema de cómo aten- 
der peticiones concurrentes a través de señales y manejadores de señales. 
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Problema 


Existen aplicaciones, como los servidores web, cuyo comportamiento es reactivo, es 
decir, a partir de la ocurrencia de un evento externo se realizan todas las operaciones 
necesarias para atender a ese evento externo. En el caso del servidor web, una cone- 
xión entrante (evento) dispararía la ejecución del código pertinente que crearía un hilo 
de ejecución para atender a dicha conexión. Pero también pueden tener comportamiento 
proactivo. Por ejemplo, una señal interna puede indicar cuándo destruir una conexión con 
un cliente que lleva demasiado tiempo sin estar accesible. 


En los videojuegos ocurre algo muy similar: diferentes entidades pueden lanzar even- 
tos que deben ser tratados en el momento en el que se producen. Por ejemplo, la pulsación 
de un botón en el joystick de un jugador es un evento que debe ejecutar el código perti- 
nente para que la acción tenga efecto en el juego. 


Solución 


En el patrón Reactor se definen una serie de actores con las siguientes responsabilida- 
des (véase figura 4.18): 













EventHandler 


+handle(event) 
+getHandle() 


A 


+regHandler() 
+unregHandler() 
+loop() 











N 
event = select(); 
for h in handlers; ConcreteEventHandler 


h->handle(event); +handle (event) 
+getHandle() 


AN 
any 0S resource 


Figura 4.18: Diagrama de clases del patrón Reactor 


Eventos: los eventos externos que puedan ocurrir sobre los recursos (Handles). Nor- 
malmente su ocurrencia es asíncrona y siempre está relaciona a un recurso deter- 
minado. 


Recursos (Handles): se refiere a los objetos sobre los que ocurren los eventos. 


La pulsación de una tecla, la expiración de un temporizador o una conexión en- 
trante en un socket son ejemplos de eventos que ocurren sobre ciertos recursos. 
La representación de los recursos en sistemas tipo GNU/Linux es el descriptor de 
fichero. 


Manejadores de Eventos: Asociados a los recursos y a los eventos que se producen 
en ellos, se encuentran los manejadores de eventos (EventHandler) que reciben una 
invocación a través del método handle() con la información del evento que se ha 
producido. 


Reactor: se trata de la clase que encapsula todo el comportamiento relativo a la 
demultiplexación de los eventos en manejadores de eventos (dispatching). Cuan- 
do ocurre un cierto evento, se busca los manejadores asociados y se les invoca el 
método handle(). 
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En general, el comportamiento sería el siguiente: 


1. Los manejadores se registran utilizando el método regHandler() del Reactor. De 
esta forma, el Reactor puede configurarse para esperar los eventos del recurso 
que el manejador espera. El manejador puede dejar de recibir notificaciones con 
unregHandler(). 


2. A continuación, el Reactor entra en el bucle infinito (Loop()), en el que se espera la 
ocurrencia de eventos. 


3. Utilizando alguna llamada al sistema, como puede ser select (), el Reactor espera 
a que se produzca algún evento sobre los recursos monitorizados. 


4. Cuando ocurre, busca los manejadores asociados a ese recurso y les invoca el mé- 
todo handle() con el evento que ha ocurrido como parámetro. 


5. El manejador recibe la invocación y ejecuta todo el código asociado al evento. 


Nótese que aunque los eventos ocurran concurrentemente el Reactor serializa las lla- 
madas a los manejadores. Por lo tanto, la ejecución de los manejadores de eventos ocurre 
de forma secuencial. 


Consideraciones 


Al utilizar un Reactor, se deben tener las siguientes consideraciones: 


1. Los manejadores de eventos no pueden consumir mucho tiempo. Si lo hacen, pue- 
den provocar un efecto convoy y, dependiendo de la frecuencia de los eventos, pue- 
den hacer que el sistema sea inoperable. En general, cuanto mayor sea la frecuencia 
en que ocurren los eventos, menos tiempo deben consumir los manejadores. 


2. Existen implementaciones de Reactors que permiten una demultiplexación concu- 
rrente, es decir, las llamadas a los handles no se serializan y ocurren en paralelo. 


3. Desde un punto de vista general, el patrón Observer tiene un comportamiento muy 
parecido. Sin embargo, el Reactor está pensado para las relaciones 1lalynolan 
como en el caso del Observer. 


4.5.7. Visitor 


El patrón Visitor proporciona un mecanismo para realizar diferentes operaciones so- 
bre una jerarquía de objetos de forma que añadir nuevas operaciones no haga necesario 
cambiar las clases de los objetos sobre los que se realizan las operaciones. 


Problema 


En el diseño de un programa, normalmente se obtienen jerarquías de objetos a través 
de herencia o utilizando el patrón Composite (véase sección 4.4.1). Considerando una 
jerarquía de objetos que sea más o menos estable, es muy probable que necesitemos rea- 
lizar operaciones sobre dicha jerarquía. Sin embargo, puede ser que cada objeto deba ser 
tratado de una forma diferente en función de su tipo. La complejidad de estas operaciones 
aumenta muchísimo. 
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Supongamos el problema de detectar las colisiones entre los objetos de un juego. 
Dada una estructura de objetos (con un estado determinado), una primera aproximación 
sería recorrer toda la estructura en busca de dichas colisiones y, en cada caso particular, 
realizar las operaciones específicas que el objeto concreto necesita. Por ejemplo, en caso 
de detectarse una colisión de un misil con un edificio se producirán una serie de acciones 
diferentes que si el misil impactara contra un vehículo. 


En definitiva, realizar operaciones sobre una estructura de objetos que mantiene un 
cierto estado puede complicar la implementación de las mismas debido a que se deben de 
tener en cuenta las particularidades de cada tipo de objeto y operación realizada. 


Solución 


El patrón Visitor se basa en la creación de dos jerarquías independientes: 


= Visitables: son los elementos de la estructura de objetos que aceptan a un determi- 
nado visitante y que le proporcionan toda la información a éste para realizar una 
determinada operación. 


= Visitantes: jerarquía de objetos que realizan una operación determinada sobre los 
elementos visitables. 


En la figura 4.19 se puede muestra un diagrama de clases genérico del patrón Visitor 
donde se muestran estas dos jerarquías. Cada visitante concreto realiza una operación 
sobre la estructura de objetos. Es posible que al visitante no le interesen todos los objetos 
y, por lo tanto, la implementación de alguno de sus métodos sea vacía. Sin embargo, lo 
importante del patrón Visitor es que se pueden añadir nuevos tipos de visitantes concretos 
y, por lo tanto, realizar nuevas operaciones sobre la estructura sin necesidad de modificar 
nada en la propia estructura. 





Visitor 


+visitElementA() 
+visitElementB() 
A 






+accept(v:Visitor) 







ConcreteVisitorl 


+visitElementA() 
+visitElementB() 


ConcreteVisitor2 


+visitElementA() 
+visitElementB() 











ElementB 
+accept(v:Visitor) 


DN 
v->visitElementA(this); 


Figura 4.19: Diagrama de clases del patrón Visitor 





+accept(v:Visitor) 






v->visitElementB(this); 


Implementación 


Como ejemplo de implementación supongamos que tenemos una escena (Scene) en 
la que existe una colección de elementos de tipo ObjectScene. Cada elemento tiene atri- 
butos como su nombre, peso y posición en la escena, es decir, name, weight y position, 
respectivamente. Se definen dos tipos visitantes: 
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= NameVisitor: mostrará los nombres de los elementos de una escena. 


= BombVisitor: modificará la posición final de todos los elementos de una escena al 
estallar una bomba. Para calcularla tendrá que tener en cuenta los valores de los 
atributos de cada objeto de la escena. 


Listado 4.14: Visitor (ejemplo) 


class ObjectScene [ 
public: 
void accept(SceneVisitorx v) [£ v->visitO0bject(this); ); 


y; 


class Scene 4 
private: 
vector<0bjectScene> _objects; 
public: 
10 void accept(SceneVisitorx* v) £ 
11 for (vector<O0bjectScene>::iterator ob = _objects.begin(); 
12 ob != _objects.end(); ob++) 
13 v->accept(v); 
14 v->visitScene(this); 
15 dd 
16 ); 
17 
18 class SceneVisitor 4 
19 virtual void visit0bject(ObjectScenex ob) = 0; 
20 virtual void visitScene(Scene* scene) = 0; 
21 y; 
22 
23 class NameVisitor : public SceneVisitor [ 
24 private: 
25 vector<string> _names; 


1 
2 
3 
4 
5 
6 
7 
8 
9 


26 public: 

27 void visit0bject(ObjectScenex ob) £ 

28 _names .push_back(ob->name) ; 

29 F; 

30 void visitScene(Scenex scene) f 

31 cout << "The scene '" << scene->name << "” has following objects:" << endl; 
32 for (vector<string>::iterator it = _names.begin(); 
33 it != _names.end(); it++) 

34 cout << *it << endl; 

35 $; 

36 y; 

37 


38 class BombVisitor : public SceneVisitor [ 
39 private: 

40 Bomb _bomb; 

41 public: 

42 BombVisitor(Bomb bomb) : _bomb(bomb)'; 
43 void visitO0bject(ObjectScenex ob) 4 


44 Point new_pos = calculateNewPosition(ob->position, 
45 ob->weight, 

46 _bomb->intensity); 

47 ob->position = new_pos; 

48 1d 

49 void visitScene(ObjectScenex scene) (7; 

50 y; 

51 


52 Scenex* scene = createScene(); 

53 SceneVisitor* name_visitor = new NameVisitor(); 

54 scene->accept(name_visitor); 

55 cis 

56 /x* bomb explosion occurs x*/ 

57 SceneVisitor* bomb_visitor = new BombVisitor(bomb); 
58 scene->accept(bomb_visitor); 
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Se ha simplificado la implementación de Scene y ObjectScene. Únicamente se ha in- 
cluido la parte relativa al patrón Visitor, es decir, la implementación de los métodos 
accept (). Nótese que es la escena quien que ejecuta accept() sobre todos sus elemen- 
tos y cada uno de ellos invoca a visit0bject(), con una referencia a sí mismo para que 
el visitante pueda extraer información. Dependiendo del tipo de Visitor instanciado, uno 
simplemente almacenará el nombre del objeto y el otro calculará si el objeto debe mover- 
se a causa de una determinada explosión. Este mecanismo se conoce como despachado 
doble o double dispatching. El objeto que recibe la invocación del accept() delega la 
implementación de lo que se debe realizar a un tercero, en este caso, al visitante. 


Finalmente, la escena también invoca al visitante para que realice las operaciones 
oportunas una vez finalizado el análisis de cada objeto. Nótese que, en el ejemplo, en el 
caso de BombVisitor no se realiza ninguna acción en este caso. 


Consideraciones 
Algunas consideraciones sobre el patrón Visitor: 


= El patrón Visitor es muy conveniente para recorrer estructuras arbóreas y realizar 
Operaciones en base a los datos almacenados. 


= En el ejemplo, la ejecución se realiza de forma secuencial ya que se utiliza un 
iterador de la clase vector. La forma en que se recorra la estructura influirá no- 
tablemente en el rendimiento del análisis de la estructura. Se puede hacer uso del 
patrón Iterator para decidir cómo escoger el siguiente elemento. 


= Uno de los problemas de este patrón es que no es recomendable si la estructura 
de objetos cambia frecuentemente o es necesario añadir nuevos tipos de objetos 
de forma habitual. Cada nuevo objeto que sea susceptible de ser visitado puede 
provocar grandes cambios en la jerarquía de los visitantes. 


4.6. Programming Idioms 


Hasta el momento, se han descrito algunos de los patrones de diseño más importantes 
que proporcionan una buena solución a determinados problemas a nivel de diseño. Todos 
ellos son aplicables a cualquier lenguaje de programación en mayor o menor medida. 
Algunos patrones de diseño son más o menos difíciles de implementar en un lenguaje de 
programación determinado. Otros se adaptan mejor a las estructuras de abstracción que el 
lenguaje proporcionan y son más fáciles de implementar. 


Sin embargo, a nivel de lenguaje de programación, existen «patrones» que hacen que 
un programador comprenda mejor dicho lenguaje y aplique soluciones mejores, e incluso 
óptimas, a la hora de resolver un problema de codificación. Los expresiones idiomáti- 
cas (o simplemente, idioms) son un conjunto de buenas soluciones de programación que 
permiten: 


= Resolver ciertos problemas de codificación asociados a un lenguaje específico. Por 
ejemplo, cómo obtener la dirección de memoria real de un objeto en C++ aunque 
esté sobreescrito el operador €. Este idiom se llama AddressOf. 


= Entender y explotar las interioridades del lenguaje y, por tanto, programar mejor. 


= Establecer un repertorio de buenas prácticas de programación para el lenguaje. 


[150] Capítulo 4 :: Patrones de Diseño 





Al igual que los patrones, los idioms tienen un nombre asociado (además de sus alias), 
la definición del problema que resuelven y bajo qué contexto, así como algunas conside- 
raciones (eficiencia, etc.). A continuación, se muestran algunos de los más relevantes. En 
la sección de «Patrones de Diseño Avanzados» se exploran más de ellos. 


4.6.1. Orthodox Canonical Form 


Veamos un ejemplo de mal uso de C++: 


*tinclude <vector> 


struct Af 
A() : a(new char[3000]) (7 
-A() £ delete [] a; ) 
charx a; 


y; 


int main() 4 
A var; 
std: :vector<A> v; 
v.push_back(var); 
return 0; 


Si compilamos y ejecutamos este ejemplo nos llevaremos una desagradable sorpresa. 


$ g++ bad.cc -o bad 

$ ./bad 

x*x** glibc detected *** ./bad: double free or corruption (!prev): 0x00000000025de010 xx 
E Ba Aca ======== 


¿Qué es lo que ha pasado? ¿No estamos reservando memoria en el constructor y libe- 
rando en el destructor? ¿Cómo es posible que haya corrupción de memoria? La solución 
al enigma es lo que no se ve en el código. Si no lo define el usuario el compilador de C++ 
añade automáticamente un constructor de copia que implementa la estrategia más simple, 
copia de todos los miembros. En particular cuando llamamos a push_back() creamos una 
copia de var. Esa copia recibe a su vez una copia del miembro var.a que es un puntero 
a memoria ya reservada. Cuando se termina main() se llama al destructor de var y del 
vector. Al destruir el vector se destruyen todos los elementos. En particular se destruye 
la copia de var, que a su vez libera la memoria apuntada por su miembro a, que apunta a 
la misma memoria que ya había liberado el destructor de var. 


Antes de avanzar más en esta sección conviene formalizar un poco la estructura que 
debe tener una clase en C++ para no tener sorpresas. Básicamente se trata de especificar 
todo lo que debe implementar una clase para poder ser usada como un tipo cualquiera: 


= Pasarlo como parámetro por valor o como resultado de una función. 
= Crear arrays y contenedores de la STL. 


= Usar algoritmos de la STL sobre estos contenedores. 


Para que no aparezcan sorpresas una clase no trivial debe tener como mínimo: 


1. Constructor por defecto. Sin él sería imposible instanciar arrays y no funcionarían 
los contenedores de la STL. 
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2. Constructor de copia. Sin él no podríamos pasar argumentos por valor, ni devolver- 
lo como resultado de una función. 


3. Operador de asignación. Sin él no funcionaría la mayoría de los algoritmos sobre 
contenedores. 


4. Destructor. Es necesario para liberar la memoria dinámica reservada. El destructor 
por defecto puede valer si no hay reserva explícita. 


A este conjunto de reglas se le llama normalmente forma canónica ortodoxa (orthodox 
canonical form). 


Además, si la clase tiene alguna función virtual, el destructor debe ser virtual. Esto es 
así porque si alguna función virtual es sobrecargada en clases derivadas podrían reservar 
memoria dinámica que habría que liberar en el destructor. Si el destructor no es virtual 
no se podría garantizar que se llama. Por ejemplo, porque la instancia está siendo usada a 
través de un puntero a la clase base. 


4.6.2. Interface Class 


En C++, a diferencia de lenguajes como Java, no existen clases interfaces, es decir, 
tipos abstractos que no proporcionan implementación y que son muy útiles para definir el 
contrato entre un objeto cliente y uno servidor. Por ello, el concepto de interfaz es muy 
importante en POO. Permiten obtener un bajo grado de acoplamiento entre las entidades 
y facilitan en gran medida las pruebas unitarias, ya que permite utilizar objetos dobles 
(mocks, stubs, etc.) en lugar de las implementaciones reales. 


Este idiom muestra cómo crear una clase que se comporta como una interfaz, utilizan- 
do métodos virtuales puros. 


El compilador fuerza que los métodos virtuales puros sean implementados por las 
clases derivadas, por lo que fallará en tiempo de compilación si hay alguna que no lo 
hace. Como resultado, tenemos que Vehicle actúa como una clase interfaz. Nótese que el 
destructor se ha declarado como virtual. Como ya se citó en la forma canónica ortodo- 
xa (sección 4.6.1), esto es una buena práctica para evitar posibles leaks de memoria en 
tiempo de destrucción de un objeto Vehicle usado polimórficamente (por ejemplo, en un 
contenedor). Con esto, se consigue que se llame al destructor de la clase más derivada. 


4.6.3. Final Class 


En Java o Cff es posible definir una clase como final, es decir, no es posible here- 
dar una clase hija de ella. Este mecanismo de protección puede tener mucho sentido en 
diferentes ocasiones: 


= Desarrollo de una librería o una API que va ser utilizada por terceros. 
= Clases externas de módulos internos de un programa de tamaño medio o grande. 


En C++, no existe este mecanismo. Sin embargo, es posible simularlo utilizando el 
idiom Final Class. 


Este idiom se basa en una regla de la herencia virtual: el constructor y destructor de 
una clase heredada virtualmente será invocado por la clase más derivada de la jerarquía. 
Como, en este caso, el destructor es privado, el compilador prohíbe la instanciación de B 
y el efecto es que no se puede heredar más allá de A. 
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Listado 4.16: Ejemplo de Interface Class 


1 class Vehicle 

2 4 

3 public: 

4 virtual -Vehicle(); 

5 virtual std::string name() = 0; 
6 virtual void run() = 0; 

7 

8 

9 


y; 


class Car: public Vehicle 
10 £ 
11 public: 
12 virtual -Car(); 
13 std: :string name() ([ return "Car"; ) 
14 void run() ( /x* ... x/ $ 
15 ); 
16 
17 class Motorbike: public Vehicle 
18 £ 
19 public: 
20 virtual -Motorbike(); 
21 std::string name() £ return "Motorbike"; ) 
22 void run() ( /* ... *x/ $ 
235 de 


Listado 4.17: Ejemplo de Final Class 


class Final 

t 
-Final() () // privado 
friend class A; 

$; 


. 


class A : virtual Final 


dt); 


00 Jou GUN 


10 class B : public B 


11 (); 

12 

13 int main (void) 

14 £ 

15 B b; // fallo de compilación 
16 ) 


4.6.4. pImpl 


Pointer To Implementation (plmpl), también conocido como Handle Body u Opaque 
Pointer, es un famoso idiom (utilizado en otros muchos) para ocultar la implementación 
de una clase en C++. Este mecanismo puede ser muy útil sobre todo cuando se tienen 
componentes reutilizables cuya declaración o interfaz puede cambiar, lo cual implicaría 
que todos sus usuarios deberían recompilar. El objetivo es minimizar el impacto de un 
cambio en la declaración de la clase a sus usuarios. 
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En C++, un cambio en las variables miembro de una clase o en los métodos inline 
puede suponer que los usuarios de dicha clase tengan que recompilar. Para resolverlo, 
la idea de plmpl es que la clase ofrezca una interfaz pública bien definida y que ésta 
contenga un puntero a su implementación, descrita de forma privada. 


Por ejemplo, la clase Vehicle podría ser de la siguiente forma: 


Listado 4.18: Ejemplo básico de clase Vehicle 


1 class Vehicle 

2 4 

3 public: 

4 void run(int distance); 
5 

6 

7. 

8 


private: 
int _wheels; 


$; 


Como se puede ver, es una clase muy sencilla ya que ofrece sólo un método público. 
Sin embargo, si queremos modificarla añadiendo más atributos o nuevos métodos priva- 
dos, se obligará a los usuarios de la clase a recompilar por algo que realmente no utilizan 
directamente. Usando pImpl, quedaría el siguiente esquema: 


Listado 4.19: Clase Vehicle usando pImpl (Vehicle.h) 


/* Interfaz publica Vehicle.h */ 


class Vehicle 
t 
public: 
void run(int distance); 


private: 

class VehicleImpl; 
VehicleImpl* _pimpl; 
$; 


Ri 
PLO000YX0UAauNA 


Listado 4.20: Implementación de Vehicle usando pImpl (Vehicle.cpp 


/* Vehicle.cpp */ 
*finclude <Vehicle.h> 


Vehicle: :Vehicle() 
t 

—pimpl = new VehicleImpl(); 
) 


10 void Vehicle::run() 
11 ( 

12 —pimpl->run(); 

13 y 
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Listado 4.21: Declaración de Vehiclelmpl (Vehiclelmpl.h 


/* VehicleImpl.h x*/ 





1 
2 
3 class VehicleImpl 
44 
5 public: 
6 void run(); 
7 
8 private: 
9 int _wheels; 
10 std: :string name; 
11 y; 
Si la clase Vehicle está bien definida, se puede cambiar su implementación sin obligar 
a sus usuarios a recompilar. Esto proporciona una mayor flexibilidad a la hora de definir, 
implementar y realizar cambios sobre la clase VehicleImpl. 
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brary), la biblioteca estándar proporcionada por C++, en el contexto del desarro- 

llo de videojuegos, discutiendo su utilización en dicho ámbito de programación. 
Asimismo, también se realiza un recorrido exhaustivo por los principales tipos de con- 
tenedores, estudiando aspectos relevantes de su implementación, rendimiento y uso en 
memoria. El objetivo principal que se pretende alcanzar es que el lector sea capaz de uti- 
lizar la estructura de datos más adecuada para solucionar un problema, justificando el 
porqué y el impacto que tiene dicha decisión sobre el proyecto en su conjunto. 


E este capítulo se proporciona una visión general de STL (Standard Template Li- 


5.1. Visión general de STL 


La biblioteca estándar de C++, STL, es sin duda una de las más utilizadas en el desa- 
rrollo de aplicaciones en este lenguaje. Además, está muy optimizada para el manejo de 
estructuras de datos y de algoritmos básicos, aunque su complejidad es elevada y el código 
fuente es poco legible para desarrolladores poco experimentados. Desde un punto de vista 
abstracto, STL es un conjunto de clases que proporciona la siguiente funcionalidad [17]: 


= Soporte a características del lenguaje, como por ejemplo la gestión de memoria e 
información relativa a los tipos de datos manejados en tiempo de ejecución. 


= Soporte relativo a aspectos del lenguaje definidos por la implementación, como por 
ejemplo el valor en punto flotante con mayor precisión. 


= Soporte para funciones que no se pueden implementar de manera óptima con las 
herramientas del propio lenguaje, como por ejemplo ciertas funciones matemáticas 
O asignación de memoria dinámica. 


= Inclusión de contenedores para almacenar datos en distintas estructuras, iteradores 
para acceder a los elementos de los contenedores y algoritmos para llevar a cabo 
operaciones sobre los mismos. 
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it = begin () ++it 


Figura 5.1: Representación gráfica del recorrido de un contenedor mediante iteradores. 


= Soporte como base común para otras bibliotecas. 


La figura 5.2 muestra una perspectiva global de la organización de STL y los diferen- 
tes elementos que la definen. Como se puede apreciar, STL proporciona una gran variedad 
de elementos que se pueden utilizar como herramientas para la resolución de problemas 
dependientes de un dominio en particular. 


Las utilidades de la biblioteca estándar se definen en el espacio de nombres std y se 
encuentran a su vez en una serie de bibliotecas, que identifican las partes fundamentales de 
STL. Note que no se permite la modificación de la biblioteca estándar y no es aceptable 
modificar su contenido mediante macros, ya que afectaría a la portabilidad del código 
desarrollado. 


En el ámbito del desarrollo de videojuegos, los contenedores juegan un papel funda- 
mental como herramienta para el almacenamiento de información en memoria. En este 
contexto, la realización un estudio de los mismos, en términos de operaciones, gestión de 
memoria y rendimiento, es especialmente importante para utilizarlos adecuadamente. Los 
contenedores están representados por dos tipos principales. Por una parte, las secuencias 
permiten almacenar elementos en un determinado orden. Por otra parte, los contenedores 
asociativos no tienen vinculado ningún tipo de restricción de orden. 


La herramienta para recorrer los contenedores está representada por el iterador. El 
uso de los iteradores en STL representa un mecanismo de abstracción fundamental para 
realizar el recorrido, el acceso y la modificación sobre los distintos elementos almace- 
nados en un contenedor. Todos los contenedores mantienen dos funciones relevantes que 
permiten obtener dos iteradores: 


1. begin(), que devuelve un iterador al primer elemento del contenedor, 


2. end(), que devuelve un iterador al elemento siguiente al último. 


El hecho de que end() devuelva un iterador al siguiente elemento al último albergado 
en el contenedor es una convención en STL que simplifica la iteración sobre los elementos 
del mismo o la implementación de algoritmos. 


Una vez que se obtiene un iterador que apunta a una parte del contenedor, es posible 
utilizarlo como referencia para acceder a los elementos contiguos. En función del tipo de 
iterador y de la funcionalidad que implemente, será posible acceder solamente al elemento 
contiguo, al contiguo y al anterior o a uno aleatorio. 


El siguiente fragmento de código muestra un ejemplo sencillo en el que se utiliza STL 
para instanciar un vector de enteros, añadir elementos y, finalmente, recorrerlo haciendo 
uso de un iterador. Como se puede apreciar en la línea (7), STL hace uso de plantillas para 
manejar los distintos contenedores, permitiendo separar la funcionalidad de los mismos 
respecto a los datos que contienen. En el ejemplo, se instancia un vector de tipos enteros. 

















































































5.1. Visión general de STL [157] 
Iteradores Algoritmos 
<iterator> Iteradores y soporte a iteradores xl ¿ 
<algorithm> algoritmos generales 
¡sesstaliós bsearch() y qsort() E, 
fe Cadenas 
<string> cadena Es Contenedores S 
<cctype> clasificación de caracteres 
<cwctype> clasificación caracteres extendidos <vector> array unidimensional 
<cstring> funciones de cadena <list> lista doblemente enlazada 
<cwchar> funciones caracteres extendidos* <deque> cola de doble extremo 
OS funciones cadena* <queue> cola 
<stack> pila 
<map> array asociativo 
Entrada/Salida <set> conjunto 
X <bitset> array de booleanos ) 
<iosfwd> declaraciones utilidades E/S 
<iostream> objetos/operaciones iostream estándar 
<ios> bases de ¡ostream e Diagnósticos SN 
<streambuf>  búferes de flujos 
<istream> plantilla de flujo de entrada a Hohs 1 de 
<ostream> lantilla de flujo de salida repro A 
: . a <stdexcept> excepciones estándar 
<iomanip> manipuladores ' ES O OE 
<sstream> flujos hacia/desde cadenas Doc - ratamient * 
<cstdlib> funciones de clasificación de caracteres ad O SS JJ) 
<fstream> flujos hacia/desde archivos 
<cstdio> familia printf() de E/S 
<cwchar> E/S caracteres dobles familia printf si 
/ grato Utilidades generales 














<utility> operadores y pares 
<functional> objetos función 
<memory> asignadores contenedores 
<ctime> fecha y hora* 





Números 








rl Soporte del lenguaje SN 
<limits> límites numéricos 

<climits> macros límites numéricos escalares* 
<cfloats> macros límites numéricos pto flotante* 
<new> gestión de memoria dinámica 
<typeinfo> soporte a identificación de tipos 
<exception> soporte al tratamiento de excepciones 
<cstddef> soporte de la biblioteca al lenguaje C 
<cstdarg> lista parám. función long. variable 
<csetjmp> rebobinado de la pila* 

<cstdlib> finalización del programa 

<ctime> reloj del sistema 

<csignal> tratamiento de señales* 


<complex> 
<valarray> 


números complejos y operaciones 
vectores númericos y operaciones 
operaciones numéricas generaliz. 
funciones matemáticas estándar 
números aleatorios* 


<numeric> 
<cmath> 
<cstdlib> 











Figura 5.2: Visión general de la organización de STL [17]. El asterisco referencia a elementos con el estilo del 


lenguaje C. 


Manejo de iteradores 

El concepto de iterador es fundamen- 
tal para recorrer e interactuar de mane- 
ra eficiente con las distintas estructuras 
de datos incluidas en la biblioteca es- 
tándar. 


Más adelante se estudirán los distintos tipos de 
contenedores y la funcionalidad que ofrecen. Sin 
embargo, el lector puede suponer que cada con- 
tenedor proporciona una funcionalidad distinta en 
función de su naturaleza, de manera que cada uno 
de ellos ofrece una API que se utilizará para acce- 


der a la misma. En el ejemplo, se utiliza en concreto la función push_back para añadir un 


elemento al final del vector. 
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Finalmente, en la línea (13) se declara un iterador de tipo vector<int> que se utilizará 
como base para el recorrido del vector. La inicialización del mismo se encuentra en la 
línea (5), es decir, en la parte de inicialización del bucle for, de manera que originalmente 
el iterador apunta al primer elemento del vector. La iteración sobre el vector se estará 
realizando hasta que no se llegue al iterador devuelto por end() (línea (16), es decir, al 
elemento posterior al último. 


ttinclude <iostream> 
*tinclude <vector> 


using namespace std; 


int main () 4 
vector<int> v; // Instanciar el vector de int. 
v.push_back(7); // Añadir información. 


v.push_back(4); 
v.push_back(6); 


vector<int>::iterator it; // Declarar el iterador. 


for (it = v.begin(); // it apunta al principio del vector 
it != v.end(); // mientras it no llegue a end(), 
++1t) // incrementar el iterador 


cout << *it << endl; // Acceso al contenido de it. 


return 0; 


Note cómo el incremento del iterador es trivial (línea (7), al igual que el acceso del 
contenido al que apunta el iterador (línea (18)), mediante una nomenclatura similar a la 
utilizada para manejar punteros. 


Por otra parte, STL proporciona un conjunto estándar de algoritmos que se pueden 
aplicar a los contenedores e iteradores. Aunque dichos algoritmos son básicos, éstos se 
pueden combinar para obtener el resultado deseado por el propio programador. Algunos 
ejemplos de algoritmos son la búsqueda de elementos, la copia, la ordenación, etc. Al 
igual que ocurre con todo el código de STL, los algoritmos están muy optimizados y 
suelen sacrificar la simplicidad para obtener mejores resultados que proporcionen una 
mayor eficiencia. 


5.2. STL y el desarrollo de videojuegos 


En la sección 1.2 se discutió una visión general de la arquitectura estructurada en 
capas de un motor de juegos. Una de esas capas es la que proporciona bibliotecas de 
desarrollo, herramientas transversales y middlewares con el objetivo de dar soporte al 
proceso de desarrollo de un videojuego (ver sección 1.2.2). STL estaría incluido en dicha 
capa como biblioteca estándar de C++, posibilitando el uso de diversos contenedores 
como los mencionados anteriormente. 


Desde un punto de vista general, a la hora de abordar el desarrollo de un videojuego, 
el programador o ingeniero tendría que decidir si utilizar STL o, por el contrario, utili- 
zar alguna otra biblioteca que se adapte mejor a los requisitos impuestos por el juego a 
implementar. 


5.2. STL y el desarrollo de videojuegos [159] 





5.2.1. Reutilización de código 


Uno de los principales argumentos para utilizar STL en el desarrollo de videojuegos 
es la reutilización de código que ya ha sido implementado, depurado y portado a distintas 
plataformas. En este contexto, STL proporciona directamente estructuras de datos y al- 
goritmos que se pueden utilizar y aplicar, respectivamente, para implementar soluciones 
dependientes de un dominio, como por ejemplo los videojuegos. 


Gran parte del código de STL está vinculado a la 
construcción de bloques básicos en el desarrollo de vi- 
deojuegos, como las listas, las tablas hash, y a algoritmos 
fundamentales como la ordenación o la búsqueda de ele- 
mentos. Además, el diseño de STL está basado en el uso 
extensivo de plantillas. Por este motivo, es posible uti- 
lizarlo para manejar cualquier tipo de estructura de datos 
sin tener que modificar el diseño interno de la propia apli- 
cación. 


Otra ventaja importante de STL es que muchos desa- a 
rrolladores y programadores de todo el mundo lo utilizan. 
Este hecho tiene un impacto enorme, ya que ha posibili- Figura 5.3: La reutilización de códi- 
tado la creación de una comunidad a nivel mundial y ha go es esencial para agilizar el desa- 
afectado al diseño y desarrollo de bibliotecas utilizadas rollo y mantenimiento de progra- 
para programar en C++. Por una parte, si alguien tiene "* 

un problema utilizando STL, es relativamente fácil bus- 

car ayuda y encontrar la solución al problema, debido a que es muy probable que alguien 
haya tenido ese mismo problema con anterioridad. Por otra parte, los desarrolladores de 
bibliotecas implementadas en C++ suelen tener en cuenta el planteamiento de STL en 
sus propios proyectos para facilitar la interoperabilidad, facilitando así el uso de dichas 
bibliotecas y su integración con STL. 








Recuerde que la reutilización de código es uno de los pilares fundamentales pa- 
uy ra afrontar el desarrollo de proyectos complejos y de gran envergadura, como por 
ejemplo los videojuegos. 











5.2.2. Rendimiento 


Uno de los aspectos críticos en el ámbito del desarrollo de videojuegos es el rendi- 
miento, ya que es fundamental para lograr un sensación de interactividad y para dotar 
de sensación de realismo el usuario de videojuegos. Recuerde que un videojuego es una 
aplicación gráfica de renderizado en tiempo real y, por lo tanto, es necesario asegurar 
una tasa de frames por segundo adecuada y en todo momento. Para ello, el rendimiento 
de la aplicación es crítico y éste viene determinado en gran medida por las herramientas 
utilizadas. 


En general, STL proporciona un muy buen rendimiento debido principalmente a que 
ha sido mejorado y optimizado por cientos de desarrolladores en estos últimos años, con- 
siderando las propiedades intrínsecas de cada uno de sus elementos y de las plataformas 
sobre las que se ejecutará. 
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STL será normalmente más eficiente que otra implementación y, por lo tanto, es el 
candidato ideal para manejar las estructuras de datos de un videojuego. Mejorar el ren- 
dimiento de STL implica tener un conocimiento muy profundo de las estructuras de datos 
a manejar y puede ser una alternativa en casos extremos y con plataformas hardware es- 
pecíficas. Si éste no es el caso, entonces STL es la alternativa directa. 


No obstante, algunas compañías tan relevantes en el ámbito del desarrollo de video- 
juegos, como EA (Electronic Arts), han liberado su propia adaptación de STL denominada 
EASTL (Electronic Arts Standard Template Library) !, justificando esta decisión en base 
a la detección de ciertas debilidades, como el modelo de asignación de memoria, o el 
hecho de garantizar la consistencia desde el punto de vista de la portabilidad. 


Además del rendimiento de STL, es importante considerar que su uso permite que el 
desarrollador se centre principalmente en el manejo de elementos propios, es decir, a nivel 
de nodos en una lista o claves en un diccionario, en lugar de prestar más importancia a 
elementos de más bajo nivel, como punteros o buffers de memoria. 


Uno de los aspectos claves a la hora de manejar de manera eficiente STL se basa 
en utilizar la herramienta adecuada para un problema concreto. Si no es así, entonces es 
fácil reducir enormemente el rendimiento de la aplicación debido a que no se utilizó, por 
ejemplo, la estructura de datos más adecuada. 





La herramienta ideal. Benjamin Franklin afirmó que si dispusiera de 8 horas para 
derribar un árbol, emplearía 6 horas para afilar su hacha. Esta reflexión se puede apli- 

(ij) car perfectamente a la hora de decidir qué estructura de datos utilizar para solventar 
un problema. 











5.2.3. Inconvenientes 


El uso de STL también puede presentar ciertos inconvenientes; algunos de ellos direc- 
tamente vinculados a su propia complejidad [3]. En este contexto, uno de los principales 
inconvenientes al utilizar STL es la depuración de programas, debido a aspectos como 
el uso extensivo de plantillas por parte de STL. Este planteamiento complica bastante la 
inclusión de puntos de ruptura y la depuración interactiva. Sin embargo, este problema no 
es tan relevante si se supone que STL ha sido extensamente probado y depurado, por lo 
que en teoría no sería necesario llegar a dicho nivel. 


Por otra parte, visualizar de manera directa el contenido de los contenedores o estruc- 
turas de datos utilizadas puede resultar complejo. A veces, es muy complicado conocer 
exactamente a qué elemento está apuntando un iterador o simplemente ver todos los ele- 
mentos de un vector. 


La última desventaja es la asignación de memoria, debido a que se pretende que 
STL se utilice en cualquier entorno de cómputo de propósito general. En este contexto, es 
lógico suponer que dicho entorno tenga suficiente memoria y la penalización por asignar 
memoria no es crítica. Aunque esta situación es la más común a la hora de plantear un 
desarrollo, en determinados casos esta suposición no se puede aplicar, como por ejemplo 
en el desarrollo de juegos para consolas de sobremesa. Note que este tipo de plataformas 
suelen tener restricciones de memoria, por lo que es crítico controlar este factor para 
obtener un buen rendimiento. 





Ihttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html 
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Una posible solución a este inconveniente consiste en utilizar asignadores de memo- 
ria personalizados cuando se utilizan contenedores específicos, de manera que el desa- 
rrollador puede controlar cómo y cuándo se asigna memoria. Obviamente, esta solución 
implica que dicho desarrollador tenga un nivel de especialización considerable, ya que 
esta tarea no es trivial. En términos general, el uso de asignadores personalizados se lleva 
a cabo cuando el desarrollo de un videojuego se encuentra en un estado avanzado. 





En general, hacer uso de STL para desarrollar un videojuego es una de las mejores al- 
ternativas posibles. En el ámbito comercial, un gran número de juegos de ordenador 

y y de consola han hecho uso de STL. Recuerde que siempre es posible personalizar 
algunos aspectos de STL, como la asignación de memoria, en función de las restric- 
ciones existentes. 





5.3. Secuencias 


La principal característica de los contenedores de secuencia es que los elementos al- 
macenados mantienen un orden determinado. La inserción y eliminación de elementos 
se puede realizar en cualquier posición debido a que los elementos residen en una secuen- 
cia concreta. A continuación se lleva a cabo una discusión de tres de los contenedores de 
secuencia más utilizados: el vector (vector), la cola de doble fin (deque) y la lista (list). 


5.3.1. Vector 


El vector es uno de los contenedores más simples y 
más utilizados de STL, ya que posibilita la inserción y 
eliminación de elementos en cualquier posición. Sin em- 
bargo, la complejidad computacional de dichas operacio- 
nes depende de la posición exacta en la que se inserta o 
elimina, respectivamente, el elemento en cuestión. Dicha 
complejidad determina el rendimiento de la operación y, 
por lo tanto, el rendimiento global del contenedor. 


Un aspecto importante del vector es que proporcio- 
na iteradores bidireccionales, es decir, es posible acceder 
tanto al elemento posterior como al elemento anterior a 
partir de un determinado iterador. Así mismo, el vector 
permite el acceso directo sobre un determinado elemen- — Figura 5.4: Los contenedores de se- 


to, de manera similar al acceso en los arrays de C. cuencia mantienen un orden determi- 
nado a la hora de almacenar elemen- 


A diferencia de lo que ocurre con los arrays, un vector — tos, posibilitando optimizar el acceso 
no tiene límite en cuanto al número de elementos que se — y £estionando la consistencia caché. 
pueden añadir. Al menos, mientras el sistema tenga me- 
moria disponible. En caso de utilizar un array, el programador ha de comprobar continua- 
mente el tamaño del mismo para asegurarse de que la insercción es factible, evitando así 
potenciales violaciones de segmento. En este contexto, el vector representa una solución 
a este tipo de problemas. 





Los vectores proporcionan operaciones para añadir y eliminar elementos al final, in- 
sertar y eliminar elementos en cualquier posición y acceder a los mismos en tiempo cons- 
tante a partir de un índice?. 





http ://www.cplusplus.com/reference/stl/vector/ 
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Implementación 





Elemento 1 
Elemento 2 





Elemento 3 





Vacío 


Figura 5.5: Implementación típica 
del contenedor vector con cabecera. 


Cabecera 


Tamaño elemento 


Típicamente, el contenido de los vectores se almace- 
na de manera contigua en un bloque de memoria, el cual 
suele contemplar el uso de espacio adicional para futuros 
elementos. Cada elemento de un vector se almacena uti- 
lizando un desplazamiento a la derecha, sin necesidad de 
hacer uso de punteros extra. De este modo, y partiendo de 
la base de que todos los elementos del vector ocupan el 
mismo tamaño debido a que son del mismo tipo, la loca- 
lización de los mismos se calcula a partir del índice en la 
secuencia y del propio tamaño del elemento. 


Los vectores utilizan una pequeña cabecera que con- 
tiene información general del contenedor, como el pun- 
tero al inicio del mismo, el número actual de elementos 
y el tamaño actual del bloque de memoria reservado (ver 
figura 5.5). 


Rendimiento 


En general, la inserción o eliminación de elementos al 
final del vector es muy eficiente. En este contexto, STL 
garantiza una complejidad constante en dichas operacio- 
nes, es decir, una complejidad O(1). Así, la complejidad 
de estas operaciones es independiente del tamaño del vec- 
tor. Además, la inserción es realmente eficiente y consiste 
en la simple copia del elemento a insertar. 


La inserción o eliminación en posiciones arbitrarias 
requiere un mayor coste computacional ya que es nece- 
sario recolocar los elementos a partir de la posición de 
inserción o eliminación en una posición más o menos, 
respectivamente. La complejidad en estos casos es lineal, 
es decir, O(n). Es importante destacar el caso en el que 
la inserción de un elemento al final del vector implique 
la reasignación y copia del resto de elementos, debido a 
que el bloque de memoria inicialmente vinculado al vec- 
tor esté lleno. Sin embargo, esta situación se puede evitar 
en bucles que requieran un rendimiento muy alto. 


A pesar de la penalización a la hora de insertar y eliminar elementos en posiciones 
aleatorias, el vector podría ser la mejor opción si el programa a implementar no suele 
utilizar esta funcionalidad o si el número de elementos a manejar es bastante reducido. 


Finalmente, el recorrido transversal de vectores es tan eficiente como el recorrido 
de elementos en un array. Para ello, simplemente hay que utilizar un iterador y alguna 
estructura de bucle, tal y como se muestra en el siguiente listado de código. 


vector<int>::iterator it; 


for (it = _vector.begin(); it != _vector.end(); ++it) 4 


) 


int valor = *it; 
// Utilizar valor... 
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Complejidad 

La nomenclatura O se suele utilizar 
para acotar superiormente la comple- 
jidad de una determinada función o 
algoritmo. Los órdenes de compleji- 


Respecto al uso de memoria, los vectores ges- 
tionan sus elementos en un gran bloque de memoria 
que permita almacenar los elementos actualmen- 
te contenidos y considere algún espacio extra pa- 
ra elementos futuros. Si el bloque inicial no pue- 


dad más utilizados son O(1) (comple- 
jidad constante), O(logn) (compleji- 
dad logarítmica), O(n) (complejidad 
lineal), O(nlogn), O(n?) (compleji- 
dad cuadrática), O(n3) (complejidad 
cúbica), O(n*) (complejidad polino- 
mial), O(b”) (complejidad exponen- 
cial). 


de albergar un nuevo elemento, entonces el vector 
reserva un bloque de memoria mayor, comúnmen- 
te con el doble de tamaño, copia el contenido del 
bloque inicial al nuevo y libera el bloque de me- 
moria inicial. Este planteamiento evita que el vec- 
tor tenga que reasignar memoria con frecuencia. En 
este contexto, es importante resaltar que un vector 
no garantiza la validez de un puntero o un iterador 
después de una inserción, ya que se podría dar esta situación. Por lo tanto, si es necesario 
acceder a un elemento en concreto, la solución ideal pasa por utilizar el índice junto con 
el operador []. 


Los vectores permiten la preasignación de un número de entradas con el objetivo 
de evitar la reasignación de memoria y la copia de elementos a un nuevo bloque. Para 
ello, se puede utilizar la operación reserve de vector que permite especificar la cantidad 
de memoria reservada para el vector y sus futuros elementos. La reserva de memoria 
explícita puede contribuir a mejorar el rendimiento de los vectores y evitar un alto número 
de operaciones de reserva. 


*tinclude <iostream> 
Htinclude <vector> 


using namespace std; 


int main () £ 
vector<int> v; 
v.reserve(4); 
cout << "Capacidad inicial: " << v.capacity() << endl; 


v.push_back(7); v.push_back(6); 
v.push_back(4); v.push_back(6); 
cout << "Capacidad actual: " << v.capacity() << endl; 


v.push_back(4); // Provoca pasar de 4 a 8. 
// Se puede evitar con v.reserve (8) al principio. 
cout << "Capacidad actual: " << v.capacity() << endl; 


return 0; 


El caso contrario a esta situación está representado por vectores que contienen da- 
tos que se usan durante un cálculo en concreto pero que después se descartan. Si esta 
situación se repite de manera continuada, entonces se está asignando y liberando el vec- 
tor constantemente. Una posible solución consiste en mantener el vector como estático y 
limpiar todos los elementos después de utilizarlos. Este planteamiento hace que el vector 
quede vacío y se llame al destructor de cada uno de los elementos previamente contenidos. 
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Finalmente, es posible aprovecharse del hecho de que los elementos de un vector se 
almacenan de manera contigua en memoria. Por ejemplo, sería posible pasar el conteni- 
do de un vector a una función que acepte un array, siempre y cuando dicha función no 
modifique su contenido [3], ya que el contenido del vector no estaría sincronizado. 


¿Cuándo usar vectores? 


Como regla general, los vectores se pueden utilizar extensivamente debido a su buen 
rendimiento. En concreto, los vectores deberían utilizarse en lugar de usar arrays está- 
ticos, ya que proporcionan un enfoque muy flexible y no es necesario tener en cuenta el 
número de elementos del mismo para aplicar una operación de inserción, por ejemplo. 


En el ámbito del desarrollo de videojuegos, algunos autores plantean utilizar el vector 
como contenedor base y plantear el uso de otros contenedores en su lugar si así lo requiere 
la aplicación a desarrollar. Mientras tanto, los vectores son la solución ideal para aspectos 
como los siguientes [3]: 


= Lista de jugadores de un juego. 
= Lista de vértices con geometría simplificada para la detección de colisiones. 


= Lista de hijos de un nodo en un árbol, siempre que el tamaño de la misma no varíe 
mucho y no haya muchos hijos por nodo. 


= Lista de animaciones asociada a una determinada entidad del juego. 
= Lista de componentes de un juego, a nivel global. 
= Lista de puntos que conforman la trayectoria de una cámara. 


= Lista de puntos a utilizar por algoritmos de Inteligencia Artificial para el cálculo de 
rutas. 


5.3.2. Deque 


Deque proviene del término inglés double-ended queue y representa una cola de doble 
fin. Este tipo de contenedor es muy parecido al vector, ya que proporciona acceso directo 
a cualquier elemento y permite la inserción y eliminación en cualquier posición, aunque 
con distinto impacto en el rendimiento. La principal diferencia reside en que tanto la 
inserción como eliminación del primer y último elemento de la cola son muy rápidas. En 
concreto, tienen una complejidad constante, es decir, O(1). 


La colas de doble fin incluyen la funcionalidad básica de los vectores pero también 
considera operaciones para insertar y eliminar elementos, de manera explícita, al principio 
del contenedor?. Sin embargo, la cola de doble fin no garantiza que todos los elementos 
almacenados residan en direcciones contiguas de memoria. Por lo tanto, no es posible 
realizar un acceso seguro a los mismos mediante aritmética de punteros. 


Implementación 


Este contenedor de secuencia, a diferencia de los vectores, mantiene varios bloques 
de memoria, en lugar de uno solo, de forma que se reservan nuevos bloques conforme 
el contenedor va creciendo en tamaño. Al contrario que ocurría con los vectores, no es 
necesario hacer copias de datos cuando se reserva un nuevo bloque de memoria, ya que 
los reservados anteriormente siguen siendo utilizados. 





http ://www.cplusplus.com/reference/stl/deque/ 
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Cabecera Bloque 1 


Tamaño elemento 


Elemento 1 


Elemento 2 





[E 


Vacío 


Elemento 5 
Bloque n Elemento 6 


Elemento j 





Elemento k 


ni iia Vacío 





Figura 5.6: Implementación típica de deque. 


La cabecera de la cola de doble fin almacena una serie de punteros a cada uno de los 
bloques de memoria, por lo que su tamaño aumentará si se añaden nuevos bloques que 
contengan nuevos elementos. 


Rendimiento 


Al igual que ocurre con los vectores, la inserción y eliminación de elementos al final 
de la cola implica una complejidad constante, mientras que en una posición aleatoria 
en el centro del contenedor implica una complejidad lineal. Sin embargo, a diferencia 
del vector, la inserción y eliminación de elementos al principio es tan rápida como al 
final. La consecuencia directa es que las colas de doble fin son el candidato perfecto para 
estructuras FIFO (First In, First Out). En el ámbito del desarrollo de videojuegos, las 
estructuras FIFO se suelen utilizar para modelar colas de mensajes o colas con prioridad 
para atender peticiones asociadas a distintas tareas. 


El hecho de manejar distintos bloques de memoria hace que el rendimiento se degrade 
mínimamente cuando se accede a un elemento que esté en otro bloque distinto. Note que 
dentro de un mismo bloque, los elementos se almacenan de manera secuencial al igual 
que en los vectores. Sin embargo, el recorrido transversal de una cola de doble fin es 
prácticamente igual de rápido que en el caso de un vector. 
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Respecto al uso de memoria, es importante resaltar que las asignaciones se producen 
de manera periódica durante el uso normal de la cola de doble fin. Por una parte, si se aña- 
den nuevos elementos, entonces se reservan nuevos bloques memoria. Por otra parte, si se 
eliminan elementos, entonces se liberan otros bloques. Sin embargo, y aunque el número 
de elementos permanezca constante, es posible que se sigan asignando nuevos bloques si, 
por ejemplo, los elementos se añaden al final y se eliminan al principio. Desde un punto 
de vista abstracto, este contenedor se puede interpretar como una ventana deslizante en 
memoria, aunque siempre tenga el mismo tamaño. 


Finalmente, y debido a la naturaleza dinámica de la cola de doble fin, no existe una 
función equivalente a la función reserve de vector. 


¿Cuándo usar deques? 


En general, la cola de doble fin puede no ser la mejor opción en entornos con res- 
tricciones de memoria, debido al mecanismo utilizado para reservar bloques de memoria. 
Desafortunadamente, este caso suele ser común en el ámbito del desarrollo de videojue- 
gos. Si se maneja un número reducido de elementos, entonces el vector puede ser una 
alternativa más adecuada incluso aunque el rendimiento se degrade cuando se elimine el 
primer elemento de la estructura. 


El uso de este contenedor no es, normalmente, tan amplio como el del vector. No 
obstante, existen situaciones en las que su utilización representa una opción muy buena, 
como por ejemplo la cola de mensajes a procesar en orden FIFO. 


5.3.3. List 


La lista es otro contenedor de secuencia que difiere de los dos anteriores. En primer 
lugar, la lista proporciona iteradores bidireccionales, es decir, iteradores que permiten 
navegar en los dos sentidos posibles: hacia adelante y hacia atrás. En segundo lugar, la 
lista no proporciona un acceso aleatorio a los elementos que contiene, como sí hacen tanto 
los vectores como las colas de doble fin. Por lo tanto, cualquier algoritmo que haga uso 
de este tipo de acceso no se puede aplicar directamente sobre listas. 


La principal ventaja de la lista es el rendimiento 


Algoritmos en listas E a > ; 
y la conveniencia para determinadas operaciones, 


La propia naturaleza de la lista permite 


que se pueda utilizar con un buen ren- suponiendo que se dispone del Iterador necesario 
dimiento para implementar algoritmos para apuntar a una determinada posición. 

o utilizar los ya existentes en la propia ; ES ñ 

biblioteca. > del La especificación de listas de STL ofrece una 


funcionalidad básica muy similar a la de cola de 
doble fin, pero también incluye funcionalidad relativa a aspectos más complejos como la 


fusión de listas o la búsqueda de elementos?*. 


Implementación 


Este contenedor se implementa mediante una lista doblemente enlazada de elemen- 
tos. Al contrario del planteamiento de los dos contenedores previamente discutidos, la 
memoria asociada a los elementos de la lista se reserva individualmente, de manera que 
cada nodo contiene un puntero al anterior elemento y otro al siguiente (ver figura 5.7). 


La lista también tiene vinculada una cabecera con información relevante, destacando 
especialmente los punteros al primer y último elemento de la lista. 





4http ://www.cplusplus.com/reference/stl/list/ 
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Cabecera 


OS Siguiente d Siguiente 


*elementos 
Elemento 1 Elemento 2 Elemento 3 


Tamaño elemento 





Figura 5.7: Implementación típica del contenedor lista. 


Rendimiento 


La principal ventaja de una lista en términos de rendimiento es que la inserción y 
eliminación de elementos en cualquier posición se realiza en tiempo constante, es decir, 
O(1). Sin embargo, para garantizar esta propiedad es necesario obtener un iterador a la 
posición deseada, operación que puede tener una complejidad no constante. 


Listado 5.4: Uso básico de listas con STL 


1 Htinclude <iostream> 

2 *tinclude <list> 

3 ¿*tinclude <stdlib.h> 

4 using namespace std; 

5 

6 class Clase ( 

7 public: 

8 Clase (int id, int num_alumnos): 

9 _id(id), _num_alumnos(num_alumnos) (+ 
10 int getld () const ([ return _id; ) 

11 int getNumAlumnos () const (£ return _num_alumnos; 


12 

13 bool operator< (const Clase €c) const ([ // Sobrecarga del operador para poder comparar clases. 
14 return (_num_alumnos < c.getNumAlumnos()); 

15 y 

16 


17 private: 

18 int _id; 

19 int _num_alumnos; 
20 y; 


22 void muestra_clases (list<Clase> lista); 
24 int main () £ 


25 list<Clase> clases; // Lista de clases. 
26 srand(time(NULL)); 


27 

28 for (int i=0; i< 7; ++i) // Inserción de clases. 
29 clases.push_back(Clase(i, int(rand() %30 + 10))); 
30 

31 muestra_clases(clases); 

32 


33 // Se ordena la lista de clases (usa la implementación del operador de sobrecarga) 
34 clases.sort(); 
35 muestra_clases(clases); 


37 return 0; 
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Una desventaja con respecto a los vectores y a las colas de doble fin es que el re- 
corrido transvesal de las listas es mucho más lento, debido a que es necesario leer un 
puntero para acceder a cada nodo y, además, los nodos se encuentran en fragmentos de 
memoria no adyacentes. Desde un punto de vista general, el recorrido de elementos en 
una lista puede ser de hasta un orden de magnitud más lento que en vectores. Además, 
las operaciones que implican el movimiento de bloques de elementos en listas se realiza 
en tiempo constante, incluso cuando dichas operaciones se realizan utilizando más de un 
contenedor. 


El planteamiento basado en manejar punteros hace que las listas sean más eficientes 
a la hora de, por ejemplo, reordenar sus elementos, ya que no es necesario realizar copias 
de datos. En su lugar, simplemente hay que modificar el valor de los punteros de acuerdo 
al resultado esperado o planteado por un determinado algoritmo. En este contexto, a ma- 
yor número de elementos en una lista, mayor beneficio en comparación con otro tipo de 
contenedores. 


El anterior listado de código mostrará el siguiente resultado por la salida estándar: 


0: 23 1: 28 2: 10 3: 17 4: 20 5: 22 6: 11 
2: 10 6: 11 3: 17 4: 20 5: 22 0: 23 1: 28 


es decir, mostrará la información relevante de los objetos de tipo Clase ordenados de 
acuerdo a la variable miembro _num_alumnos, ya que el valor de dicha variable se utiliza 
como criterio de ordenación. Este criterio se especifica de manera explícita al sobrecargar 
el operador < (líneas (14-16). Internamente, la lista de STL hace uso de esta información 
para ordenar los elementos y, desde un punto de vista general, se basa en la sobrecarga de 
dicho operador para ordenar, entre otras funciones, tipos de datos definidos por el propio 
usuario. 





Respecto al uso en memoria, el planteamiento de la lista reside en reservar pequeños 
bloques de memoria cuando se inserta un nuevo elemento en el contenedor. La principal 
ventaja de este enfoque es que no es necesario reasignar datos. Además, los punteros e 
iteradores a los elementos se preservan cuando se realizan inserciones y eliminaciones, 
posibilitando la implementación de distintas clases de algoritmos. 


Evidentemente, la principal desventaja es que 


Asignación de memoria ] > pa A l 
cas1 cualquier operación implica una nueva asig- 


El desarrollo de juegos y la gestión de 


servidores de juego con altas cargas nación de memoria. Este inconveniente se puede 
computacionales implica la implemen- solventar utilizando asignadores de memoria per- 
tación asignadores de memoria perso- sonalizados, los cuales pueden usarse incluso para 
nalizados. Este planteamiento permite mejorar la penalización que implica tener los datos 


mejorar el rendimiento de alternativas dd 1 dos dela list distint £ 
clásicas basadas en el uso de stacks y asociados a loS nodos de la ista en distintas partes 


heaps. de la memoria. 


En el ámbito del desarrollo de videojuegos, es- 
pecialmente en plataformas con restricciones de memoria, las listas pueden degradar el 
rendimiento debido a que cada nodo implica una cantidad extra, aunque pequeña, de me- 
moria para llevar a cabo su gestión. 


¿Cuándo usar listas? 


Aunque las listas proporcionan un contenedor de uso general y se podrían utilizar 
como sustitutas de vectores o deques, su bajo rendimiento al iterar sobre elementos y 
la constante de reserva de memoria hacen que las listas no sean el candidato ideal para 
aplicaciones de alto rendimiento, como los videojuegos. Por lo tanto, las listas deberían 
considerarse como una tercera opción tras valores los otros dos contenedores previamente 
comentados. 


5.4. Contenedores asociativos 
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Propiedad Vector Deque List 

VE al final O(1) O(1) O(1) 

VE al principio O(n) O(1) O(1) 

T/E en el medio O(n) O(n) O(1) 
Recorrido Rápido Rápido Menos rápido 
Asignación memoria | Raramente | Periódicamente | Con cada I/E 
Acceso memoria sec. | Sí Casi siempre No 
Invalidación iterador | Tras I/E Tras 1/E Nunca 











Tabla 5.1: Resumen de las principales propiedades de los contenedores de secuencia previamente estudiados 


(T/E = inserción/eliminación). 


A continuación se listan algunos de los posibles usos de listas en el ámbito del desa- 


rrollo de videojuegos: 


= Lista de entidades del juego, suponiendo un alto número de inserciones y elimina- 


ciones. 


= Lista de mallas a renderizar en un frame en particular, suponiendo una ordenación 
en base a algún criterio como el material o el estado. En general, se puede evaluar 
el uso de listas cuando sea necesario aplicar algún criterio de ordenación. 


= Lista dinámica de posibles objetivos a evaluar por un componente de Inteligencia 
Artificial, suponiendo un alto número de inserciones y eliminaciones. 


5.4. Contenedores asociativos 


Mientras las secuencias se basan en la premisa de 
mantener posiciones relativas respecto a los elementos 
que contienen, los contenedores asociativos se desmarcan 
de dicho enfoque y están diseñados con el objetivo de op- 
timizar el acceso a elementos concretos del contenedor 
de la manera más rápida posible. 


En el caso de las secuencias, la búsqueda de elemen- 
tos en el peor de los casos es de complejidad lineal, es 
decir, O(n), ya que podría ser necesario iterar sobre to- 
dos los elementos del contenedor para dar con el elemento 
deseado. En algunos casos, es posible obtener una com- 
plejidad logarítmica, es decir, O(logn), si los elementos 
de la secuencia están ordenados y se aplica una búsqueda 
binaria. Sin embargo, en general no es deseable mantener 
los elementos ordenados debido a que el rendimiento se 
verá degradado a la hora de insertar y eliminar elementos. 


S 


Figura 5.8: Los contenedores aso- 
ciativos se basan en hacer uso de un 
elemento clave para acceder al con- 
tenido. 


Por el contrario, los contenedores asociativos permiten obtener una complejidad loga- 
rítmica o incluso constante para encontrar un elemento concreto. Para ello, los elementos 
del contenedor asociativo se suelen indexar utilizando una clave que permite acceder al 


propio valor del elemento almacenado. 
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5.4.1. Set y multiset 


En STL, un conjunto o sef sigue la misma filosofía que un conjunto matemático, es de- 
cir, sirve como almacén para una serie de elementos. En esencia, un elemento se encuentra 
en un conjunto o no se encuentra en el mismo. El contenedor set tiene como característica 
principal que los elementos almacenados en el mismo actúan como las propias claves. 
La inserción de objetos se realiza con la operación insert, la eliminación con erase y la 


búsqueda mediante find”. Esta operación tiene una complejidad logarítmica. 


Un conjunto sólo tiene una instancia de cada objeto, de manera que insertar varias ve- 
ces el mismo objeto produce el mismo resultado que insertarlo una única vez, es decir, no 
modifica el conjunto. De este modo, un conjunto es el candidato ideal para introducir un 
número de objetos y obviar los que sean redundantes. Este enfoque es mucho más eficien- 
te que, por ejemplo, mantener una lista y hacer una búsqueda de elementos duplicados, 


ya que el algoritmo implicaría una complejidad cuadrática, es decir, O(n2). 


STL también soporte el contenedor multiset o multi-conjunto?, que sí permite mante- 
ner varias copias de un mismo objeto siempre y cuando se inserte en más de una ocasión. 
Este contenedor también permite acceder al número de veces que una determinada ins- 
tancia se encuentra almacenada mediante la operación count. 


A continuación se muestra un ejemplo de uso básico de los conjuntos. El aspecto 
más relevante del mismo es la declaración del conjunto en la línea (17), de manera que 
posibilite almacenar elementos enteros y, al mismo tiempo, haga uso de la definición de 
la clase ValorAbsMenos para definir un criterio de inclusión de elementos en el conjunto. 
Desde un punto de vista general, los conjuntos posibilitan la inclusión de criterios para 
incluir o no elementos en un conjunto. En el ejemplo propuesto, este criterio se basa en 
que la distancia entre los enteros del conjunto no ha de superar un umbral (DISTANCIA) 
para poder pertenecer al mismo. Note cómo la comparación se realiza en las líneas 
con el operador <, es decir, mediante la función menor. Este enfoque es bastante común 
en STL, en lugar de utilizar el operador de igualdad. 





Htinclude <iostream> 
*tinclude <set> 
ttinclude <algorithm> 
using namespace std; 
ífdefine DISTANCIA 5 


struct ValorAbsMenos Y 
bool operator() (const inté v1, const intá v2) const ( 
return (abs(vl1 - v2) < DISTANCIA); 


) 
y; 


void recorrer (set<int, ValorAbsMenos> valores); 


int main () 4 
set<int, ValorAbsMenos> valores; 


valores.insert(5); valores.insert(9); 
valores.insert(3); valores.insert(7); 


recorrer(valores); 


return 0; 





Shttp: //www. cplusplus .com/reference/stl/set/ 
Shttp://www.cplusplus.com/reference/stl/multiset/ 
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Figura 5.9: Implementación típica del contenedor set. 


La salida al ejecutar el listado de código anterior se expone a continuación: 


795 


es decir, el elemento 3 no se encuentra en el conjunto debido a que su distancia con el 
elemento 9 es mayor a la definida en el umbral (5). 


Finalmente, set y multiset son contenedores asociativos ordenados, debido a que 
los elementos se almacenan utilizando un cierto orden, el cual se basa en una función de 
comparación como la discutida anteriormente. Este enfoque permite encontrar elementos 
rápidamente e iterar sobre los mismos en un determinado orden. 


Implementación 


En términos generales, los conjuntos se implementan utilizando un árbol binario 
balanceado (ver figura 5.9) para garantizar que la complejidad de las búsquedas en el 
peor caso posible sea logarítmica, es decir, O(logn). Cada elemento, al igual que ocurre 
con la lista, está vinculado a un nodo que enlaza con otros manteniendo una estructura de 
árbol. Dicho árbol se ordena con la función de comparación especificada en la plantilla. 
Aunque este enfoque es el más común, es posible encontrar alguna variación en función 
de la implementación de STL utilizada. 


Rendimiento 


La principal baza de los conjuntos es su gran rendimiento en operaciones relativas a la 
búsqueda de elementos, garantizando una complejidad logarítmica en el peor de los ca- 
sos. Sin embargo, es importante tener en cuenta el tiempo invertido en la comparación de 
elementos, ya que ésta no es trivial en caso de manejar estructuras de datos más comple- 
jas, como por ejemplo las matrices. Así mismo, la potencia de los conjuntos se demuestra 
especialmente cuando el número de elementos del contenedor comienza a crecer. Aun- 
que los conjuntos permiten realizar búsquedas eficientes, es importante tener en cuenta la 
complejidad asociada a la propia comparación de elementos, especialmente si se utilizan 
estructuras de datos complejas. 
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Una alternativa posible para buscar elementos de manera eficiente puede ser un vector, 
planteando para ello una ordenación de elementos seguida de una búsqueda binaria. Este 
planteamiento puede resultar eficiente si el número de búsquedas es muy reducido y el 
número de accesos es elevado. 


La inserción de elementos en un árbol balanceado tiene una complejidad logarítmica, 
pero puede implicar la reordenación de los mismos para mantener balanceada la estructu- 
ra. Por otra parte, el recorrido de los elementos de un conjunto es muy similar al de listas, 
es decir, se basa en el uso de manejo de enlaces a los siguientes nodos de la estructura. 


Respecto al uso de memoria, la implementación basada en árboles binarios balancea- 
dos puede no ser la mejor opción ya que la inserción de elementos implica la asignación 
de un nuevo nodo, mientras que la eliminación implica la liberación del mismo. 


¿Cuándo usar sets y multisets? 


En general, este tipo de contenedores asociativos están ideados para situaciones espe- 
cíficas, como por ejemplo el hecho de manejar conjuntos con elementos no redundantes 
o cuando el número de búsquedas es relevante para obtener un rendimiento aceptable. En 
el ámbito del desarrollo de videojuegos, este tipo de contenedores se pueden utilizar para 
mantener un conjunto de objetos de manera que sea posible cargar de manera automática 
actualizaciones de los mismos, permitiendo su sobreescritura en función de determinados 
criterios. 


5.4.2. Map y multimap 


En STL, el contenedor map se puede interpretar co- 
mo una extensión de los conjuntos con el principal ob- 
Clave jetivo de optimizar aún más la búsqueda de elementos. 
Para ello, este contenedor distingue entre clave y valor 
para cada elemento almacenado en el mismo. Este plan- 
teamiento difiere de los conjuntos, ya que estos hacen uso 
del propio elemento como clave para ordenar y buscar. En 
esencia, un map es una secuencia de pares <clave, valor>, 
proporcionando una recuperación rápida del valor a par- 
tir de dicha clave. Así mismo, un map se puede entender 
como un tipo especial de array que permite la indexación 
de elementos mediante cualquier tipo de datos. De hecho, 
el contenedor permite el uso del operador []. 


Mapping 


El multimap permite manejar distintas instancias de 
la misma clave, mientras que el map no. Es importante 
resaltar que no existe ninguna restricción respecto al va- 
lor, es decir, es posible tener un mismo objeto como valor 
asociado a distintas claves. 


La principal aplicación de un map es manejar estruc- 
turas de tipo diccionario que posibiliten el acceso inme- 
a e diato a un determinado valor dada una clave. Por ejemplo, 
Figura 5.10: El proceso de utilizar Sería posible asociar un identificador único a cada una de 
una clave en un map para obtener , E a 
un valor se suele denominar común- Jas entidades de un juego y recuperar los punteros asocia- 
mente mapping. dos a las propias entidades cuando así sea necesario. De 
este modo, es posible utilizar sólo la memoria necesaria 
cuando se añaden nuevas entidades. 


Valor 
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Tanto el map” como el multimap* son contenedores asociativos ordenados, por lo que 
es posible recorrer su contenido en el orden en el que estén almacenados. Sin embargo, 
este orden no es el orden de inserción inicial, como ocurre con los conjuntos, sino que 
viene determinado por aplicar una función de comparación. 


Implementación 


La implementación típica de este tipo de contenedores es idéntica a la de los conjun- 
tos, es decir, mediante un árbol binario balanceado. Sin embargo, la diferencia reside 
en que las claves para acceder y ordenar los elementos son objetos distintos a los propios 
elementos. 


Rendimiento 


El rendimiento de estos contenedores es prácticamente idéntico al de los conjuntos, 
salvo por el hecho de que las comparaciones se realizan a nivel de clave. De este modo, 
es posible obtener cierta ventaja de manejar claves simples sobre una gran cantidad de 
elementos complejos, mejorando el rendimiento de la aplicación. Sin embargo, nunca 
hay que olvidar que si se manejan claves más complejas como cadenas o tipos de datos 
definidos por el usuario, el rendimiento puede verse afectado negativamente. 


Por otra parte, el uso del operador [] no tie- El operador [] 
ne el mismo rendimiento que en vectores, ya que Elpaao s piel ps 


implica realizar la búsqueda del elemento a partir ceder, escribir o actualizar información 
de la clave y, por lo tanto, no sería de un orden de sobre algunos contenedores. Sin em- 
complejidad constante sino logarítmico. Al usar es- bargo, es importante considerar el im- 
te operador, también hay que tener en cuenta que si Pacto en el rendimiento al utilizar di- 

q , cho operador, el cual vendrá determi- 
se escribe sobre un elemento que no existe, enton- nado por el contenedor usado. 
ces éste se añade al contenedor. Sin embargo, si se 
intenta leer un elemento que no existe, entonces el resultado es que el elemento por de- 
fecto se añade para la clave en concreto y, al mismo tiempo, se devuelve dicho valor. El 
siguiente listado de código muestra un ejemplo. 


Como se puede apreciar, el listado de código muestra características propias de STL 
para manejar los elementos del contenedor: 


= En la línea (7) se hace uso de pair para declarar una pareja de valores: 1) un iterador 
al contenedor definido en la línea (6) y 11) un valor booleano. Esta estructura se 
utilizará para recoger el valor de retorno de una inserción (línea (14). 


= Las líneas muestran inserciones de elementos. 


= En la línea (15) se recoge el valor de retorno al intentar insertar un elemento con una 
clave ya existente. Note cómo se accede al iterador en la línea (17) para obtener el 
valor previamente almacenado en la entrada con clave 2. 


= La línea (28) muestra un ejemplo de inserción con el operador [], ya que la clave 3 
no se había utilizado previamente. 


= La línea (23) ejemplifica la inserción de un elemento por defecto. Al tratarse de 
cadenas de texto, el valor por defecto es la cadena vacía. 





Thttp ://www.cplusplus.com/reference/stl/map/ 
8Shttp ://www.cplusplus.com/reference/stl/multimap/ 
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ttinclude <iostream> 
*tinclude <map> 


using namespace std; 


int main () £ 
map<int, string> jugadores; 
pair<map<int, string>::iterator, bool> ret; 


// Insertar elementos. 
jugadores.insert(pair<int, string>(1, "Luis")); 
jugadores.insert(pair<int, string>(2, "Sergio")); 


// Comprobando elementos ya insertados... 
ret = jugadores.insert(pair<int, string>(2, "David")); 


if (ret.second == false) ( 
cout << "El elemento 2 ya existe "; 
cout << "con un valor de " << ret.first->second << endl; 


y 
jugadores[3] = "Alfredo"; // Inserción con []... 


// Caso excepcional; se añade valor por defecto... 
const strings j_aux = jugadores[4]; // jugadores[4] = 


return 0; 


Ante esta situación, resulta deseable hacer uso de la operación find para determinar si 
un elemento pertenece o no al contenedor, accediendo al mismo con el iterador devuelto 
por dicha operación. Así mismo, la inserción de elementos es más eficiente con insert 
en lugar de con el operador [], debido a que este último implica un mayor número de 
copias del elemento a insertar. Por el contrario, [] es ligeramente más eficiente a la hora 
de actualizar los contenidos del contenedor en lugar de insert. 


Respecto al uso de memoria, los mapas tienen un comportamiento idéntico al de los 
conjuntos, por lo que se puede suponer los mismos criterios de aplicación. 





Usando referencias. Recuerde consultar información sobre las operaciones de cada 
uno de los contenedores estudiados para conocer exactamente su signatura y cómo 
invocarlas de manera eficiente. 











¿Cuándo usar maps y multimaps? 


En general, estos contenedores se utilizan como diccionarios de rápido acceso que 
permiten indexar elementos a partir de manejadores o identificadores únicos. Sin embar- 
go, también es posible utilizar claves más complejas, como por ejemplo cadenas. Algunas 
de las principales aplicaciones en el desarrollo de videojuegos son las siguientes: 


= Mantenimiento de un diccionario con identificadores únicos para mapear las distin- 
tas entidades del juego. De este modo, es posible evitar el uso de punteros a dichas 
entidades. 


= Mecanismo de traducción entre elementos del juego, como por ejemplo entre identi- 
ficadores numéricos y cadenas de texto vinculadas a los nombres de los personajes. 


5.5. Adaptadores de secuencia [175] 


























Propiedad Set Map 

VE elementos O(logn) O(logn) 
Búsqueda O(logn) O(logn) 
Recorrido Más lento que lista — Más lento que lista 
Asignación memoria | Con cada I/E Con cada I/E 
Acceso memoria sec. | No No 

Invalidación iterador | Nunca Nunca 








Tabla 5.2: Resumen de las principales propiedades de los contenedores asociativos previamente estudiados (1/E 
= inserción/eliminación). 


5.5. Adaptadores de secuencia 


STL proporciona el concepto de adaptadores para 
proporcionar una funcionalidad más restringida sobre un 
contenedor existente sin la necesidad de que el propio PS s 
desarrollador tenga que especificarla. Este enfoque se ba- 
sa en que, por ejemplo, los contenederos de secuencia 
existentes tienen la flexibilidad necesaria para comportar- 
se como otras estructuras de datos bien conocidas, como 
por ejemplo las pilas o las colas. 


Un pila es una estructura de datos que solamente per- 
mite añadir y eliminar elementos por un extremo, la ci- 
ma. En este contexto, cualquier conteneder de secuencia 
discutido anteriormente se puede utilizar para proporcio- 
nar dicha funcionalidad. En el caso particular de STL, es 
posible manejar pilas e incluso especificar la implementa- Elemento 2 
ción subyacente que se utilizará, especificando de manera 
explícita cuál será el contenedor de secuencia usado. 


Elemento 1 


Elemento 3 


Aunque sería perfectamente posible delegar en el pro- 
gramador el manejo del contenedor de secuencia para que 
se comporte como, por ejemplo, una pila, en la prácti- 
ca existen dos razones importantes para la definición de 
adaptadores: 


Elemento i 

1. La declaración explícita de un adaptador, como una 
pila o stack, hace que sea el código sea mucho más 
claro y legible en términos de funcionalidad. Por 
ejemplo, declarar una pila proporciona más infor- 
mación que declarar un vector que se comporte co- 
mo una pila. Esta aproximación facilita la interope- Elemento n 
rabilidad con otros programadores. 





2. El compilador tiene más información sobre la 6S=- Figura 5.115 Visión abstracta de mua 
tructura de datos y, por lo tanto, puede contribuir — pila o stack. Los elementos solamen- 
a la detección de errores con más eficacia. Si se — te se añaden o eliminan por un extre- 
utiliza un vector para modelar una pila, es posible "o: la Cima, 
utilizar alguna operación que no pertenezca a la in- 
terfaz de la pila. 
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LIFO. La pila está diseña para operar en un contexto LIFO (Last In, First Out) (last- 
uy in first-out), es decir, el elemento que se apiló más recientemente será el primero en 
salir de la pila. 





5.5.1. Stack 


El adaptador más sencillo en STL es la pila o stack?. Las principales operaciones sobre 
una pila son la inserción y eliminación de elementos por uno de sus extremos: la cima. En 
la literatura, estas operaciones se conocen como push y pop, respectivamente. 


La pila es más restrictiva en términos funcionales que los distintos contenedores de 
secuencia previamente estudiados y, por lo tanto, se puede implementar con cualquiera 
de ellos. Obviamente, el rendimiento de las distintas versiones vendrá determinado por el 
contenedor elegido. Por defecto, la pila se implementa utilizando una cola de doble fin. 


El siguiente listado de código muestra cómo hacer uso de algunas de las operaciones 
más relevantes de la pila para invertir el contenido de un vector. 


Htinclude <iostream> 
*tinclude <stack> 
*tinclude <vector> 
using namespace std; 


int main () £ 
vector<int> fichas; 
vector<int>::iterator it; 
stack<int> pila; 


for (int i=0; i< 10; i++) // Rellenar el vector 
fichas.push_back(i); 


for (it = fichas.begin(); it != fichas.end(); ++it) 
pila.push(*it); // Apilar elementos para invertir 


fichas.clear(); // Limpiar el vector 


while (!pila.empty()) £ // Rellenar el vector 
fichas.push_back(pila.top()); 
pila.pop(); 

y 


return 0; 


5.5.2. Queue 


Al igual que ocurre con la pila, la cola o queue!? es otra estructura de datos de uso muy 
común que está representada en STL mediante un adaptador de secuencia. Básicamente, la 
cola mantiene una interfaz que permite la inserción de elementos al final y la extracción 
de elementos sólo por el principio. En este contexto, no es posible acceder, insertar y 
eliminar elementos que estén en otra posición. 





http://www. cplusplus .com/reference/stl/stack/ 
lO http://www. cplusplus.com/reference/stl/queue/ 
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Por defecto, la cola utiliza la implementación de la 
cola de doble fin, siendo posible utilizar la implementa- 
ción de la lista. Sin embargo, no es posible utilizar el vec- 
tor debido a que este contenedor no proporciona la ope- 
ración push_front, requerida por el propio adaptador. De 
cualquier modo, el rendimiento de un vector para elimi- 
nar elementos al principio no es particularmente bueno, 
ya que tiene una complejidad lineal. 


5.5.3. Cola de prioridad 


STL también proporciona el adaptador cola de priori- 
dad o priority queue!! como caso especial de cola previa- 
mente discutido. La diferencia entre los dos adaptadores 
reside en que el elemento listo para ser eliminado de la 
cola es aquél que tiene una mayor prioridad, no el ele- 
mento que se añadió en primer lugar. 


Así mismo, la cola con prioridad incluye cierta fun- 
cionalidad específica, a diferencia del resto de adaptado- 
res estudiados. Básicamente, cuando un elemento se aña- 
de a la cola, entonces éste se ordena de acuerdo a una 
función de prioridad. 


Por defecto, la cola con prioridad se apoya en la im- 
plementación de vector, pero es posible utilizarla también 
con deque. Sin embargo, no se puede utilizar una lista de- 
bido a que la cola con prioridad requiere un acceso alea- 
torio para insertar eficientemente elementos ordenados. 


La comparación de elementos sigue el mismo esque- 
ma que el estudiado en la sección 5.4.1 y que permitía 
definir el criterio de inclusión de elementos en un con- 
junto, el cual estaba basado en el uso del operador menor 
que. 


La cola de prioridad se puede utilizar para múltiples 
aspectos en el desarrollo de videojuegos, como por ejem- 


Inserción 


-<«—— 


Elemento 1 


Elemento 2 


Elemento 3 





Elemento i 


Elemento n 


Wi 


Extracción 


Figura 5.12: Visión abstracta de una 
cola o queue. Los elementos sola- 
mente se añaden por el final y se eli- 
minan por el principio. 


plo la posibilidad de mantener una estructura ordenada por prioridad con aquellos objetos 
que están más cercanos a la posición de la cámara virtual. Así, este contenedor ofrece 
mayor flexibilidad para determinadas situaciones en las que son necesarias esquemas ba- 


sados en la importancio de los elementos a gestionar. 
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juego. En particular, se discutirán las arquitecturas típicas del bucle de juego, ha- 

ciendo especial hincapié en un esquema basado en la gestión de los estados de un 
juego. Como caso de estudio concreto, en este capítulo se propone una posible imple- 
mentación del bucle principal mediante este esquema haciendo uso de las bibliotecas que 
Ogre3D proporciona. 


E n este capítulo se cubren aspectos esenciales a la hora de afrontar el diseño de un 


Así mismo, este capítulo discute la gestión de recursos y, en concreto, la gestión de 
sonido y de efectos especiales. La gestión de recursos es especialmente importante en el 
ámbito del desarrollo de videojuegos, ya que el rendimiento de un juego depende en gran 
medida de la eficiencia del subsistema de gestión de recursos. 


Finalmente, la gestión del sistema de archivos, junto con aspectos básicos de entrada/- 
salida, también se estudia en este capítulo. Además, se plantea el diseño e implementación 
de un importador de datos que se puede utilizar para integrar información multimedia a 
nivel de código fuente. 


6.1. El bucle de juego 
6.1.1. El bucle de renderizado 


Hace años, cuando aún el desarrollo de videojuegos 2D era el estándar en la indus- 
tria, uno de los principales objetivos de diseño de los juegos era minimizar el número de 
píxeles a dibujar por el pipeline de renderizado con el objetivo de maximizar la tasa de 
fps del juego. Evidentemente, si en cada una de las iteraciones del bucle de renderizado 
el número de píxeles que cambia es mínimo, el juego correrá a una mayor velocidad. 
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Esta técnica es en realidad muy parecida a la que se plantea en el desarrollo de interfa- 
ces gráficas de usuario (GUI (Graphical User Interface)), donde gran parte de las mismas 
es estática y sólo se producen cambios, generalmente, en algunas partes bien definidas. 
Este planteamiento, similar al utilizado en el desarrollo de videojuegos 2D antiguos, está 
basado en redibujar únicamente aquellas partes de la pantalla cuyo contenido cambia. 
Dicha técnica se suele denominar rectangle invalidation. 


En el desarrollo de videojuegos 3D, aunque mante- 
niendo la idea de dibujar el mínimo número de primitivas 
necesarias en cada iteración del bucle de renderizado, la 
filosofía es radicalmente distinta. En general, al mismo 
tiempo que la cámara se mueve en el espacio tridimensio- 
nal, el contenido audiovisual cambia continuamente, por 
lo que no es viable aplicar técnicas tan simples como la 
mencionada anteriormente. 





La consecuencia directa de este esquema es la 
Figura 6.1: El bucle de juego repre-— necesidad de un bucle de renderizado que mues- 
senta la estructura de control princi- tg Jos distintas imágenes o frames percibidas por 
pal de cualquier juego y gobierna su > g y ; 
funcionamiento y la transición entre 14 Cámara virtual con una velocidad lo suficiente- 
los distintos estados del mismo. mente elevada para transmitir una sensación de reali- 


dad. 


El siguiente listado de código muestra la estructura general de un bucle de renderi- 
zado. 


Listado 6.1: Esquema general de un bucle de renderizado. 


while (true) € 
// Actualizar la cámara, 
// normalmente de acuerdo a un camino prefijado. 
update_camera (); 


// Actualizar la posición, orientación y 
// resto de estado de las entidades del juego. 
update_scene_entities (); 


10 // Renderizar un frame en el buffer trasero. 
11 render_scene (); 


13 // Intercambiar el contenido del buffer trasero 
14 // con el que se utilizará para actualizar el 


15 // dispositivo de visualización. 
16 swap_buffers (); 
17 $ 


6.1.2. Visión general del bucle de juego 


Como ya se introdujo en la sección 1.2, en un motor de juegos existe una gran variedad 
de subsistemas o componentes con distintas necesidades. Algunos de los más importantes 
son el motor de renderizado, el sistema de detección y gestión de colisiones, el subsistema 
de juego o el subsistema de soporte a la Inteligencia Artificial. 


6.1. El bucle de juego [181] 





La mayoría de estos componentes han de actualizarse periódicamente mientras el jue- 
go se encuentra en ejecución. Por ejemplo, el sistema de animación, de manera sincroni- 
zada con respecto al motor de renderizado, ha de actualizarse con una frecuencia de 30 
Ó 60 Hz con el objetivo de obtener una tasa de frames por segundo lo suficientemente 
elevada para garantizar una sensación de realismo adecuada. Sin embargo, no es nece- 
sario mantener este nivel de exigencia para otros componentes, como por ejemplo el de 
Inteligencia Artificial. 


De cualquier modo, es necesario un planteamiento que permita actualizar el estado 
de cada uno de los subsistemas y que considere las restricciones temporales de los mis- 
mos. Típicamente, este planteamiento se suele abordar mediante el bucle de juego, cuya 
principal responsabilidad consiste en actualizar el estado de los distintos componentes 
del motor tanto desde el punto de vista interno (ej. coordinación entre subsistemas) como 
desde el punto de vista externo (ej. tratamiento de eventos de teclado o ratón). 


// Pseudocódigo de un juego tipo "Pong". 
int main (int argc, charx* argv[]) £ 
init_game(); // Inicialización del juego. 


// Bucle del juego. 
while (1) £ 


capture_events(); // Capturar eventos externos. 


if (exitKeyPressed()) // Salida. 


break; 
move_paddles(); // Actualizar palas. 
move_ball (); // Actualizar bola. 
collision_detection(); // Tratamiento de colisiones. 


// ¿Anotó algún jugador? 

if (ballReachedBorder(LEFT_PLAYER)) 4 
score(RIGHT_PLAYER); 
reset_ball (); 


) 

if (ballReachedBorder(RIGHT_PLAYER)) 4 
score(LEFT_PLAYER); 
reset_ball (); 


7 


render (); // Renderizado. 


Antes de discutir algunas de las arquitecturas más utilizadas para modelar el bucle de 
juego, resulta interesante estudiar el anterior listado de código, el cual muestra una manera 
muy simple de gestionar el bucle de juego a través de una sencilla estructura de control 
iterativa. Evidentemente, la complejidad actual de los videojuegos comerciales requiere 
un esquema que sea más general y escalable. Sin embargo, es muy importante mantener 
la simplicidad del mismo para garantizar su mantenibilidad. 





Keep it simple, Stupid! La filosofía KISS (Keep it simple, Stupid!) se adapta per- 
fectamente al planteamiento del bucle de juego, en el que idealmente se implementa 

YN un enfoque sencillo, flexible y escalable para gestionar los distintos estados de un 
juego. 
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6.1.3. Arquitecturas típicas del bucle de juego 





Figura 6.2: El hardware de Atari 
Pong estaba especialmente pensado 
para el manejo de las dos palas que 
forman el juego. 


message 
dispatching 


Sistema 


operativo 





Figura 6.3: Esquema gráfico de 
una arquitectura basada en message 
pumps. 


La arquitectura del bucle de juego se puede imple- 
mentar de diferentes formas mediante distintos plantea- 
mientos. Sin embargo, la mayoría de ellos tienen en co- 
mún el uso de uno o varios bucles de control que gobier- 
nan la actualización e interacción con los distintos com- 
ponentes del motor de juegos. En esta sección se reali- 
za un breve recorrido por las alternativas más populares, 
resaltando especialmente un planteamiento basado en la 
gestión de los distintos estados por los que puede atrave- 
sar un juego. Esta última alternativa se discutirá con un 
caso de estudio detallado que hace uso de Ogre. 


Tratamiento de mensajes en Windows 


En las plataformas Windows'M, los juegos han de 
atender los mensajes recibidos por el propio sistema ope- 
rativo y dar soporte a los distintos componentes del pro- 
pio motor de juego. Típicamente, en estas plataformas se 
implementan los denominados message pumps [5], como 
responsables del tratamiento de este tipo de mensajes. 


Desde un punto de vista general, el planteamiento de 
este esquema consiste en atender los mensajes del pro- 
pio sistema operativo cuando llegan, interactuando con el 
motor de juegos cuando no existan mensajes del sistema 
operativo por procesar. En ese caso se ejecuta una itera- 
ción del bucle de juego y se repite el mismo proceso. 


La principal consecuencia de este enfoque es que los 
mensajes del sistema operativo tienen prioridad con res- 
pecto a aspectos críticos como el bucle de renderizado. 
Por ejemplo, si la propia ventana en la que se está ejecu- 
tando el juego se arrastra o su tamaño cambia, entonces el 
juego se congelará a la espera de finalizar el tratamiento 
de eventos recibidos por el propio sistema operativo. 


Esquemas basados en retrollamadas 


El concepto de retrollamada o callback, introducido 
de manera implícita en la discusión del patrón MVC de 
la sección 4.4.4, consiste en asociar una porción de códi- 
go para atender un determinado evento o situación. Este 
concepto se puede asociar a una función en particular o a 
un objeto. En este último caso, dicho objeto se denomina- 
rá callback object, término muy usado en el desarrollo de 
interfaces gráficas de usuario y en el área de los sistemas 
distribuidos. 


A continuación se muestra un ejemplo de uso de fun- 
ciones de retrollamada planteado en la biblioteca GLUT, 


la cual está estrechamente ligada a la biblioteca GL, utilizada para tratar de manera simple 


eventos básicos. 
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[183] 





Listado 6.3: Ejemplo de uso de retrollamadas con OpenGL. 


1 Htinclude <GL/glut.h> 

2 Htinclude <GL/glu.h> 

3 *tinclude <GL/gl.h> 

4 

5 // Se omite parte del código fuente... 

6 

7 void update (unsigned char key, int x, int y) [ 
8 Rearthyear += 0.2; 

9 Rearthday += 5.8; 

10 glutPostRedisplay(); 


11 ) 

12 

13 int main (int argc, charx* argv) ( 

14 glutInit($argc, argv); 

15 

16 glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE) ; 
17 glutInitWindowSize(640, 480); 

18 glutCreateWindow("Session +04 - Solar System"); 
19 

20 // Definición de las funciones de retrollamada. 
21 glutDisplayFunc (display); 

22 glutReshapeFunc(resize); 

23 // Eg. update se ejecutará cuando el sistema 
24 // capture un evento de teclado. 

25 // Signatura de glutKeyboardFunc: 

26 // void glutKeyboardFunc(void (*func) 

27 // (unsigned char key, int x, int y)); 

28 glutKeyboardFunc (update) ; 

29 

30 glutMainLoop(); 

31 

32 return 0; 

33 ) 


Desde un punto de vista abstracto, las funciones de retrollamada se suelen utilizar 
como mecanismo para rellenar el código fuente necesario para tratar un determinado tipo 
de evento. Este esquema está directamente ligado al concepto de framework, entendido 
como una aplicación construida parcialmente y que el desarrollador ha de completar para 


proporcionar una funcionalidad específica. 


Algunos autores [5] definen a Ogre3D como un fra- 
mework que envuelve a una biblioteca que proporcio- 
na, principalmente, funcionalidad asociada a un motor 
de renderizado. Sin embargo, ya se ha discutido cómo 
Ogre3D proporciona una gran cantidad de herramientas 
para el desarrollo de aplicaciones gráficas interactivas en 
3D. 


Las instancias de la clase Ogre::FrameListener son 
un ejemplo representativo de objetos de retrollamada, con 
el objetivo de que el desarrollador pueda decidir las ac- 
ciones que se han de ejecutar antes y después de que se 
produzca una iteración en el bucle de renderizado. Dicha 
funcionalidad está representada por las funciones virtua- 
les frameStarted() y frameEnded(), respectivamente. En 


eS 

Figura 6.4: Un framework propor- 
ciona al desarrollador una serie de 
herramientas para solucionar proble- 
mas dependientes de un dominio. El 
propio desarrollador tendrá que uti- 
lizar las herramientas disponibles y 
ajustarlas para proporcionar una bue- 
na solución. 


el Módulo 2, Programación Gráfica, se discute en profundidad un ejemplo de uso de esta 


clase. 
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Tratamiento de eventos 


En el ámbito de los juegos, un evento representa un cambio en el estado del propio 
juego o en el entorno. Un ejemplo muy común está representado por el jugador cuando 
pulsa un botón del joystick, pero también se pueden identificar eventos a nivel interno, 
como por ejemplo la reaparición o respawn de un NPC en el juego. 


Gran parte de los motores de juegos incluyen un subsistema específico para el trata- 
miento de eventos, permitiendo al resto de componentes del motor o incluso a entidades 
específicas registrarse como partes interesadas en un determinado tipo de eventos. Este 
planteamiento está muy estrechamente relacionado con el patrón Observer. 


El tratamiento de eventos es un aspecto transversal a otras arquitecturas diseñadas para 
tratar el bucle de juego, por lo que es bastante común integrarlo dentro de otros esquemas 
más generales, como por ejemplo el que se discute a continuación y que está basado en la 
gestión de distintos estados dentro del juego. 





Canales de eventos. Con el objetivo de independizar los publicadores y los suscrip- 
(1) tores de eventos, se suele utilizar el concepto de canal de eventos como mecanismo 


de abstracción. 





Esquema basado en estados 


Desde un punto de vista general, los juegos se pueden dividir en una serie de etapas 
o estados que se caracterizan no sólo por su funcionamiento sino también por la interac- 
ción con el usuario o jugador. Típicamente, en la mayor parte de los juegos es posible 
diferenciar los siguientes estados: 


= Introducción o presentación, en la que se muestra al usuario aspectos generales del 
juego, como por ejemplo la temática del mismo o incluso cómo jugar. 


= Menú principal, en la que el usuario ya puede elegir entre los distintos modos de 
juegos y que, normalmente, consiste en una serie de entradas textuales identificando 
las opciones posibles. 


= Juego, donde ya es posible interactuar con la propia aplicación e ir completando 
los objetivos marcados. 


= Finalización o game over, donde se puede mostrar información sobre la partida 
previamente jugada. 


Evidentemente, esta clasificación es muy gene- 
ral ya que está planteada desde un punto de vista 


Finite-state machines 


Las máquinas de estados o autómatas 


representan modelos matemáticos uti- muy abstracto. P or ejemplo, si consideramos as- 
lizados para diseñar programas y lógi- pectos más específicos como por ejemplo el uso 
ca digital. En el caso del desarrollo de de dispositivos como PlayStation Move'M, Wiimo- 
videojuegos se pueden usar para mo- TM z TM e E B 

delar diagramas de estados para, por teo Kinect**, sería necesario incluir un estado 
ejemplo, definir los distintos compor- de calibración antes de poder utilizar estos disposi- 


tamientos de un personaje. tivos de manera satisfactoria. 
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Figura 6.5: Visión general de una máquina de estados finita que representa los estados más comunes en cual- 
quier juego. 


Por otra parte, existe una relación entre cada 
uno de estos estados que se manifiesta en forma de transiciones entre los mismos. Por 
ejemplo, desde el estado de introducción sólo será posible acceder al estado de menú 
principal, pero no será posible acceder al resto de estados. En otras palabras, existirá 
una transición que va desde introducción a menú principal. Otro ejemplo podría ser la 
transición existente entre finalización y menú principal. 


Este planteamiento basado en estados también debería poder manejar varios estados 
de manera simultánea para, por ejemplo, contemplar situaciones en las que sea necesario 
ofrecer algún tipo de menú sobre el propio juego en cuestión. 


En la siguiente sección se discute en profundidad un caso de estudio en el que se 
utiliza Ogre3D para implementar un sencillo mecanismo basado en la gestión de estados. 
En dicha discusión se incluye un gestor responsable de capturar los eventos externos, 
como por ejemplo las pulsaciones de teclado o la interacción mediante el ratón. 


6.1.4. Gestión de estados de juego con Ogre3D 


Como ya se ha comentado, los juegos normalmente atraviesan una serie de estados 
durante su funcionamiento normal. En función del tipo de juego y de sus características, 
el número de estados variará significativamente. Sin embargo, es posible plantear un es- 
quema común, compartido por todos los estados de un juego, que sirva para definir un 
modelo de gestión general, tanto para la interacción con los estados como para las transi- 
ciones existentes entre ellos. 


La solución discutida en esta sección!, que a su vez está basada en el artículo Mana- 
ging Game States in C++. se basa en definir una clase abstracta, GameState, que contiene 
una serie de funciones virtuales a implementar en los estados específicos de un juego. En 
C++, las clases abstractas se definen mediante funciones virtuales puras y sirven para 
explicitar el contrato funcional entre una clase y sus clases derivadas. 


El siguiente listado de código muestra el esqueleto de la clase GameState implemen- 
tada en C++. Como se puede apreciar, esta clase es abstracta ya que mantiene una serie de 
funciones miembro como virtuales puras, con el objetivo de forzar su implementación en 
las clases que deriven de ella y que, por lo tanto, definan estados específicos de un juego. 
Estas funciones virtuales puras se pueden dividir en tres grandes bloques: 





lLa solución discutida aquí se basa en la planteada en el WiKi de Ogre3D, disponible en http://www. 
ogre3d.org/tikiwiki/Managing+Game+States+with+0GRE 
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Figura 6.6: Diagrama de clases del esquema de gestión de estados de juego con Ogre3D. En un tono más oscuro 
se reflejan las clases específicas de dominio. 


1. Gestión básica del estado (líneas (19-22), para definir qué hacer cuando se entra, 
sale, pausa o reanuda el estado. 


2. Gestión básica de tratamiento de eventos (líneas (26-33)), para definir qué hacer 
cuando se recibe un evento de teclado o de ratón. 


3. Gestión básica de eventos antes y después del renderizado (líneas (37-33), opera- 
ciones típicas de la clase Ogre:: FrameListener. 


Adicionalmente, existe otro bloque de funciones relativas a la gestión básica de tran- 
siciones (líneas (41-48)), con operaciones para cambiar de estado, añadir un estado a la pila 
de estados y volver a un estado anterior, respectivamente. Las transiciones implican una 
interacción con la entidad GameManager, que se discutirá posteriormente. 


La figura 6.6 muestra la relación de la clase GameState con el resto de clases, así 
como tres posibles especializaciones de la misma. Como se puede observar, esta clase 
está relacionada con GameManager, responsable de la gestión de los distintos estados y 
de sus transiciones. 


Sin embargo, antes de pasar a discutir esta clase, en el diseño discutido se contempla 
la definición explícita de la clase InputManager, como punto central para la gestión de 
eventos de entrada, como por ejemplo los de teclado o de ratón. La clase InputManager 
implementa el patrón Singleton mediante las utilidades de Ogre3D. Es posible utilizar 
otros esquemas para que su implementación no depende de Ogre y se pueda utilizar con 
otros frameworks. 


El InputManager sirve como interfaz para las entidades que estén interesadas en pro- 
cesar eventos de entrada (como se discutirá más adelante), ya que mantiene operaciones 
para añadir y eliminar listeners de dos tipos: 1) OIS::KeyListener y 11) OIS::MouseListener. 
De hecho, esta clase hereda de ambas clases. Además, implementa el patrón Singleton con 
el objetivo de que sólo exista una única instancia de la misma. 
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Listado 6.4: Clase GameState. 


1 Hifndef GameState_H 

2 *define GameState_H 

3 

4 *tinclude <0Ogre.h> 

5 Htinclude <0IS/0IS.h> 

6 

7 *tinclude "GameManager.h" 

8 *tinclude "InputManager.h" 

9 

10 // Clase abstracta de estado básico. 
11 // Definición base sobre la que extender 
12 // los estados del juego. 

13 class GameState 4 





14 

15 public: 

16 GameState() () 
17 


18 // Gestión básica del estado. 

19 virtual void enter () = 0; 

20 virtual void exit () = 0; 

21 virtual void pause () = 0; 

22 virtual void resume () = 0; 

23 

24 // Gestión básica para el tratamiento 

25 // de eventos de teclado y ratón. 

26 virtual void keyPressed (const OIS::KeyEvent €e) = 0; 
27 virtual void keyReleased (const OIS::KeyEvent de) = 0; 
28 

29 virtual void mouseMoved (const 0OIS::MouseEvent 8e) = 0; 
30 virtual void mousePressed (const 0IS::MouseEvent úe, 


31 OIS: :MouseButtonID id) = 0; 

32 virtual void mouseReleased (const 0OIS::MouseEvent €e, 
33 OIS::MouseButtonID id) = 0; 

34 


35 // Gestión básica para la gestión 

36 // de eventos antes y después de renderizar un frame. 
37 virtual bool frameStarted (const Ogre: :FrameEventá evt) 
38 virtual bool frameEnded (const Ogre: :FrameEventá evt) = 
39 

40 // Gestión básica de transiciones. 

41 void changeState (GameStatex state) £ 


=0; 
0; 


42 GameManager: :getSingletonPtr()->changeState(state); 
43 J 

44 void pushState (GameStatex* state) ( 

45 GameManager: :getSingletonPtr()->pushState(state); 
46 J 

47 void popState () 4 

48 GameManager: :getSingletonPtr()->popState(); 

49 y 

50 

51 y; 

52 

53 Hendif 


En la sección privada de InputManager se declaran funciones miembro (líneas (49-47)) 
que se utilizarán para notificar a los listeners registrados en el InputManager acerca de 
la existencia de eventos de entrada, tanto de teclado como de ratón. Este planteamiento 
garantiza la escalabilidad respecto a las entidades interesadas en procesar eventos de en- 
trada. Las estructuras de datos utilizadas para almacenar los distintos tipos de listeners 
son elementos de la clase map de la biblioteca estándar de C++, indexando los mismos 
por el identificador textual asociado a los listeners. 
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Por otra parte, es importante destacar las variables miembro _keyboard y _mouse 
que se utilizarán para capturar los eventos de teclado y ratón, respectivamente. Dicha 
captura se realizará en cada frame mediante la función capture(), definida tanto en el 
InputManager como en OIS:: Keyboard y OIS::Mouse. 


Listado 6.5: Clase InputManager. 


1 // SE OMITE PARTE DEL CÓDIGO FUENTE. 
2 // Gestor para los eventos de entrada (teclado y ratón) 
3 class InputManager : public Ogre: :Singleton<InputManager>, 
public 0IS::KeyListener, public OIS: :MouseListener ( 
public: 

InputManager (); 

virtual —InputManager (); 


WO JoOu.pa 


void initialise (Ogre: :RenderWindow *renderWindow); 
10 void capture (); 


12 // Gestión de listeners. 
13 void addKeyListener (OIS::KeyListener *keyListener, 


14 const std: :stringá instanceName) ; 
15 void addMouseListener (0IS::MouseListener *mouseListener, 
16 const std: :stringú instanceName ); 


17 void removeKeyListener (const std::stringu instanceName); 

18 void removeMouseListener (const std::stringú instanceName); 
19 void removeKeyListener (0IS::KeyListener *keyListener); 

20 void removeMouseListener (OIS::MouseListener *mouseListener); 


22 OIS: :Keyboardx* getKeyboard (); 
23 OIS: :Mousex getMouse (); 


25 // Heredados de Ogre: :Singleton. 
26 static InputManagerá getSingleton (); 
27 static InputManagerx* getSingletonPtr (); 


29 private: 

30 // Tratamiento de eventos. 

31 // Delegará en los listeners. 

32 bool keyPressed (const OIS::KeyEvent €e); 
33 bool keyReleased (const OIS::KeyEvent Ue); 


35 bool mouseMoved (const OIS::MouseEvent $e); 
36 bool mousePressed (const OIS: :MouseEvent de, 


37. OIS: :MouseButtonID id); 

38 bool mouseReleased (const 0IS::MouseEvent de, 
39 OIS::MouseButtonID id); 

40 


41 OIS: :InputManager *_inputSystem; 

42 OIS: :Keyboard *_keyboard; 

43 OIS: :Mouse *_mouse; 

44 std: :map<std::string, OIS: :KeyListenerx> _keyListeners; 

45 std: :map<std::string, OIS: :MouseListener*x> _mouseListeners; 
46 y; 


El siguiente listado de código muestra la clase GameManager, que representa a la 
entidad principal de gestión del esquema basado en estados que se discute en esta sección. 
Esta clase es una derivación de de Ogre::Singleton para manejar una única instancia y de 
tres clases clave para el tratamiento de eventos. En concreto, GameManager hereda de 
los dos tipos de listeners previamente comentados con el objetivo de permitir el registro 
con el InputManager. 


6.1. 


El bucle de juego [189] 





Listado 6.6: Clase GameManager. 


1 
2 
3 
4 


5 
6 
7 
8 
9 


10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 


// SE OMITE PARTE DEL CÓDIGO FUENTE. 
class GameState; 


class GameManager : public Ogre: :FrameListener, public Ogre: :Singleton<GameManager>, 
public 0IS::KeyListener, public 0IS::MouseListener 

t 

public: 
GameManager (); 
—GameManager (); // Limpieza de todos los estados. 


// Para el estado inicial. 
void start (GameStatex state); 


// Funcionalidad para transiciones de estados. 
void changeState (GameStatex state); 

void pushState (GameStatex* state); 

void popState (); 


// Heredados de Ogre: :Singleton... 


protected: 
Ogre: :Rootx* _root; 
Ogre: :SceneManager* _sceneManager; 
Ogre: :RenderWindowx _renderWindow; 


// Funciones de configuración. 
void loadResources (); 
bool configure (); 


// Heredados de FrameListener. 
bool frameStarted (const Ogre: :FrameEventá evt); 
bool frameEnded (const Ogre: :FrameEventá evt); 


private: 
// Funciones para delegar eventos de teclado 
// y ratón en el estado actual. 
bool keyPressed (const OIS::KeyEvent €e); 
bool keyReleased (const 0IS::KeyEvent e); 


bool mouseMoved (const OIS::MouseEvent de); 
bool mousePressed (const OIS::MouseEvent e, OIS::MouseButtonID id); 
bool mouseReleased (const OIS::MouseEvent €e, OIS::MouseButtonID id); 


// Gestor de eventos de entrada. 
InputManager x_inputMgr; 

// Estados del juego. 

std: :stack<GameStatex> _states; 


y; 


Note que esta clase contiene una función miembro start() (línea (12), definida de ma- 


nera explícita para inicializar el gestor de juego, establecer el estado inicial (pasado como 
parámetro) y arrancar el bucle de renderizado. 
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Listado 6.7: Clase GameManager. Función start(). 


void 

GameManager: :start 
(GameState* state) 
t 


_root = new Ogre: :Root(); 


if (!configure()) 


1 
2 
3 
4 
5 // Creación del objeto Ogre: :Root. 
6 
7 
8 


9 return; 

10 

11 loadResources(); 

12 

13 _inputMgr = new InputManager; 

14 _inputMgr->initialise(_renderWindow); 

15 

16 // Registro como key y mouse listener... 

17 _inputMgr->addKeyListener(this, "GameManager"); 
18 _inputMgr->addMouseListener(this, "GameManager"); 
19 

20 // El GameManager es un FrameListener. 

21 _root->addFrameListener(this); 

22 

23 // Transición al estado inicial. 

24 changeState (state); 

25 

26 // Bucle de rendering. 

27 _root->startRendering(); 

28 ) 


PauseState 
PlayState 
IntroState 








PlayState 
IntroState 





Figura 6.7: Actualización de la pi- 
la de estados para reanudar el juego 
(evento teclado ”p”). 


La clase GameManager mantiene una estructura de 
datos denominada _states que refleja las transiciones en- 
tre los diversos estados del juego. Dicha estructura se ha 
implementado mediante una pila (clase stack de STL) ya 
que refleja fielmente la naturaleza de cambio y gestión de 
estados. Para cambiar de un estado A a otro B, suponien- 
do que A sea la cima de la pila, habrá que realizar las 
Operaciones siguientes: 


1. Ejecutar exit() sobre A. 
2. Desapilar A. 
3. Apilar B (pasaría a ser el estado activo). 


4. Ejecutar enter() sobre B. 


El listado de código 6.8 muestra una posible imple- 
mentación de la función changeState() de la clase Game- 
Manager. Note cómo la estructura de pila de estados per- 
mite un acceso directo al estado actual (cima) para llevar 
a cabo las operaciones de gestión necesarias. Las transi- 
ciones se realizan con las típicas operaciones de push y 


pop. 
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Otro aspecto relevante del diseño de esta clase es la delegación de eventos de entrada 
asociados a la interacción por parte del usuario con el teclado y el ratón. El diseño dis- 
cutido permite delegar directamente el tratamiento del evento al estado activo, es decir, 
al estado que ocupe la cima de la pila. Del mismo modo, se traslada a dicho estado la 
implementación de las funciones frameStarted() y frameEnded(). El listado de código 6.9 
muestra cómo la implementación de, por ejemplo, la función keyPressed() es trivial. 


Listado 6.8: Clase GameManager. Función changeState(). 


1 void 

2 GameManager: :changeState 

3 (GameStatex state) 

4 1 

5 // Limpieza del estado actual. 

6 if (!_states.empty()) £ 

7 // exit() sobre el último estado. 
8 _states.top()->exit(); 

9 // Elimina el último estado. 
10 _states.pop(); 
11 y 
12 // Transición al nuevo estado. 
13 _states.push(state); 
14 // enter() sobre el nuevo estado. 
15 _states.top()->enter(); 
16 ) 


Listado 6.9: Clase GameManager. Función keyPressed(). 


bool 

GameManager: :keyPressed 

(const OIS::KeyEvent Se) 

t 
_states.top()->keyPressed(e); 
return true; 


, 


JXO0UBaUNA 


6.1.5. Definición de estados concretos 


Este esquema de gestión de estados general, el cual contiene una clase genérica Ga- 
meState, permite la definición de estados específicos vinculados a un juego en particular. 
En la figura 6.6 se muestra gráficamente cómo la clase GameState se extiende para definir 
tres estados: 


= IntroState, que define un estado de introducción o inicialización. 


= PlayState, que define el estado principal de un juego y en el que se desarrollará la 
lógica del mismo. 


= PauseState, que define un estado de pausa típico en cualquier tipo de juego. 


La implementación de estos estados permite hacer explícito el comportamiento del 
juego en cada uno de ellos, al mismo tiempo que posibilita las transiciones entre los 
mismos. Por ejemplo, una transición típica será pasar del estado PlayState al estado Pau- 
seState. 
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Figura 6.8: Capturas de pantalla del juego Supertux. Izquierda, estado de introducción; medio, estado de juego; 
derecha, estado de pausa. 


A la hora de llevar a cabo dicha implementación, se ha optado por utilizar el patrón 
Singleton, mediante la clase Ogre::Singleton, para garantizar que sólo existe una instacia 
de un objeto por estado. 


El siguiente listado de código muestra una posible declaración de la clase IntroState. 
Como se puede apreciar, esta clase hace uso de las funciones típicas para el tratamiento 
de eventos de teclado y ratón. 


Listado 6.10: Clase IntroState. 


1 // SE OMITE PARTE DEL CÓDIGO FUENTE. 

2 class IntroState : public Ogre::Singleton<IntroState>, 
3 public GameState 
4 

5 public: 

6 IntroState() (7 

7 

8 void enter (); void exit (); 

9 void pause (); void resume (); 


11 void keyPressed (const OIS::KeyEvent e); 
12 void keyReleased (const 0OIS::KeyEvent e); 
13 // Tratamiento de eventos de ratón... 

14 // frameStarted(), frameEnded().. 


16 // Heredados de Ogre: :Singleton. 
17 static IntroStates getSingleton (); 
18 static IntroStatex getSingletonPtr (); 


20 protected: 

21 Ogre: :Rootx* _root; 

22 Ogre: :SceneManager* _sceneMgr; 
23 Ogre: :Viewport* _viewport; 

24 Ogre: :Camerax _camera; 

25 bool _exitGame; 

26 y; 


Así mismo, también especifíca la funcionalidad vinculada a la gestión básica de esta- 
dos. Recuerde que, al extender la clase GameState, los estados específicos han de cumplir 
el contrato funcional definido por dicha clase abstracta. 


Finalmente, la transición de estados se puede gestionar de diversas formas. Por ejem- 
plo, es perfectamente posible realizarla mediante los eventos de teclado. En otras palabras, 
la pulsación de una tecla en un determinado estado sirve como disparador para pasar a 
otro estado. Recuerde que el paso de un estado a otro puede implicar la ejecución de las 
funciones exit() o pause(), dependiendo de la transición concreta. 
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El siguiente listado de código muestra las transiciones entre el estado de juego y el 
estado de pausa y entre éste último y el primero, es decir, la acción comúnmente conocida 
como reanudación (resume). Para ello, se hace uso de la tecla ”p”. 


void PlayState::keyPressed (const OIS::KeyEvent €e) ( 
if (e.key == OIS::KC_P) // Tecla p ->PauseState. 
pushState(PauseState: :getSingletonPtr()); 
) 


void PauseState::keyPressed (const OIS::KeyEvent 8€e) ( 
if (e.key == OIS::KC_P) // Tecla p ->Estado anterior 
popState(); 


Note cómo la activación del estado de pausa provoca apilar dicho estado en la pila 
(pushState() en la línea (7)), mientras que la reanudación implica desapilarlo (popState() 


en la línea (16). 


6.2. Gestión básica de recursos 


En esta sección se discute la gestión básica de los recursos, haciendo especial hincapié 
en dos casos de estudio concretos: i) la gestión básica del sonido y ii) el sistema de 
archivos. Antes de llevar a cabo un estudio específico de estas dos cuestiones, la primera 
sección de este capítulo introduce la problemática de la gestión de recursos en los motores 
de juegos. Así mismo, se discuten las posibilidades que el framework Ogre3D ofrece para 
gestionar dicha problemática. 


En el caso de la gestión básica del sonido, el lector será capaz de manejar una serie 
de abstracciones, en torno a la biblioteca multimedia SDL, para integrar música y efectos 
de sonido en los juegos que desarrolle. Por otra parte, en la sección relativa a la ges- 
tión del sistema de archivos se planteará la problemática del tratamiento de archivos y se 
estudiarán técnicas de entrada/salida asíncrona. 


Debido a la naturaleza multimedia de los motores de juegos, una consecuencia di- 
recta es la necesidad de gestionar distintos tipos de datos, como por ejemplo geometría 
tridimensional, texturas, animaciones, sonidos, datos relativos a la gestión de física y 
colisiones, etc. Evidentemente, esta naturaleza tan variada se ha de gestionar de forma 
consistente y garantizando la integridad de los datos. 


Por otra parte, las potenciales limitaciones hardware de la plataforma sobre la que se 
ejecutará el juego implica que sea necesario plantear un mecanismo eficiente para cargar 
y liberar los recursos asociados a dichos datos multimedia. Por lo tanto, una máxima del 
motor de juegos es asegurarse que solamente existe una copia en memoria de un determi- 
nado recurso multimedia, de manera independiente al número de instancias que lo estén 
utilizando en un determinado momento. Este esquema permite optimizar los recursos y 
manejarlos de una forma adecuada. 


Un ejemplo representativo de esta cuestión está representado por las mallas poligo- 
nales y las texturas. Si, por ejemplo, siete mallas comparten la misma textura, es decir, 
la misma imagen bidimensional, entonces es deseable mantener una única copia de la 
textura en memoria principal, en lugar de mantener siete. En este contexto, la mayoría 
de motores de juegos integran algún tipo de gestor de recursos para cargar y gestionar 
la diversidad de recursos que se utilizan en los juegos de última generación. El gestor 
de recursos o resource manager se suele denominar comúnmente media manager O asset 
manager. 
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Figura 6.9: Captura de pantalla del videojuego Lemmings 2. Nunca la gestión de recursos fue tan importante... 


6.2.1. Gestión de recursos con Ogre3D 


Ogre facilita la carga, liberación y gestión de recursos mediante un planteamiento 
bastante sencillo centrado en optimizar el consumo de memoria de la aplicación gráfica. 
Recuerde que la memoria es un recurso escaso en el ámbito del desarrollo de videojuegos. 


Debido a las restricciones hardware que una de- 


Carga de niveles , : é 
terminada plataforma de juegos puede imponer, re- 


Una de las técnicas bastantes comunes 


a la hora de cargar niveles de juego sulta fundamental hacer uso de un mecanismo de 
consiste en realizarla de manera previa gestión de recursos que sea flexible y escalable pa- 
al acceso a dicho nivel. Por ejemplo, ra garantizar el diseño y gestión de cualquier tipo 
a de recurso, junto con la posibilidad de cargarlo y 
de en vel al ela para adelantar liberarlo en tiempo de ejecución, respectivamente. 
el proceso de carga. El mismo plante- Por ejemplo, si piensa en un juego de plataformas 
amiento se puede utilizar para la carga estructurado en diversos niveles, entonces no sería 
de texturas en escenarios. lógico hacer una carga inicial de todos los niveles 


al iniciar el juego. Por el contrario, sería más ade- 
cuado cargar un nivel cuando el jugador vaya a acceder al mismo. 


En Ogre, la gestión de recursos se lleva a cabo utilizando principalmente cuatro clases 
(ver figura 6.10): 


= Ogre::Singleton, con el objetivo de garantizar que sólo existe una instancia de un 
determinado recurso o gestor. 


= Ogre::ResourceManager, con el objetivo de centralizar la gestión del pool de re- 
cursos de un determinado tipo. 


= Ogre::Resource, entidad que representa a una clase abstracta que se puede asociar 
a recursos específicos. 
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Figura 6.10: Diagrama de clases de las principales clases utilizadas en Ogre3D para la gestión de recursos. En 
un tono más oscuro se reflejan las clases específicas de dominio. 













































= Ogre::SharedPtr, clase que permite la gestión inteligente de recursos que necesi- 
tan una destrucción implícita. 


Básicamente, el desarrollador que haga uso del planteamiento que Ogre ofrece para 
la gestión de recursos tendrá que implementar algunas funciones heredadas de las clases 
anteriormente mencionadas, completando así la implementación específica del dominio, 
es decir, específica de los recursos a gestionar. Más adelante se discute en detalle un 
ejemplo relativo a los recursos de sonido. 





Una de las ideas fundamentales de la carga de recursos se basa en almacenar en 


y memoria principal una única copia de cada recurso. Este se puede utilizar para re- 
presentar o gestionar múltiples entidades. 











6.2.2. Gestión básica del sonido 


Introducción a SDL 


SDL (Simple Directmedia Layer) es una biblioteca 
multimedia y multiplataforma ampliamente utilizada en 
el ámbito del desarrollo de aplicaciones multimedia. Des- 
de un punto de vista funcional, SDL proporciona una serie 
de APIs para el manejo de vídeo, audio, eventos de en- 
trada, multi-hilo o renderizado con OpenGL, entre otros Simple Directmedis Layer 
aspectos. Desde un punto de vista abstracto, SDL propor- e 
ciona una API consistente de manera independiente a la 


plataforma de desarrollo Figura 6.11: Logo de la biblioteca 


multiplataforma Simple Directmedia 
SDL está bien estructurado y es fácil de utilizar. La Layer. 

filosofía de su diseño se puede resumir en ofrecer al desa- 

rrollador diversas herramientas que se pueden utilizar de manera independiente, en lugar 

de manejar una biblioteca software de mayor envergadura. Por ejemplo, un juego podría 

hacer uso de la biblioteca SDL únicamente para la gestión de sonido, mientras que la parte 

gráfica sería gestionada de manera independiente (utilizando Ogre3D, por ejemplo). 
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SDL se puede integrar perfectamente con OpenGL para llevar a cabo la inicialización 
de la parte gráfica de una aplicación interactiva, delegando en SDL el propio tratamiento 
de los eventos de entrada. Hasta ahora, en el módulo 2 (Programación Gráfica) se había 
utilizado la biblioteca GLUT (OpenGL Utility Toolkit) para implementar programas que 
hicieran uso de OpenGL. Sin embargo, SDL proporciona un gran número de ventajas con 


respecto a esta alternativa?: 


= SDL fue diseñado para programadores de videojuegos. 
= Es modular, simple y portable. 


= Proporciona soporte para la gestión de eventos, la gestión del tiempo, el manejo 
de sonido, la integración con dispositivos de almacenamiento externos como por 
ejemplo CDs, el renderizado con OpenGL e incluso la gestión de red (networking). 





SDL y Civilization. El port a sistemas GNU Linux del juego Civilization se realizó 
uy haciendo uso de SDL. En este caso particular, los personajes se renderizaban hacien- 
do uso de superficies. 











Event handlers El concepto de superficie como estructura de 
BE-poshiita la deltición de aque datos es esencial en SDL, ya que posibilita el trata- 
tecturas multi-capa para el tratamiento miento de la parte gráfica. En esencia, una superfi- 
de eventos, facilitando así su delega- cie representa un bloque de memoria utilizado pa- 
ción por parte del código dependiente ra almacenar una región rectangular de píxeles. El 
del dominio. principal objetivo de diseño es agilizar la copia de 


superficies tanto como sea posible. Por ejemplo, una superficie se puede utilizar para ren- 
derizar los propios caracteres de un juego. 


El siguiente listado de código muestra un ejemplo de integración de OpenGL en SDL, 
de manera que SDL oculta todos los aspectos dependientes de la plataforma a la hora de 
inicializar el núcleo de OpenGL. Es importante resaltar que OpenGL toma el control del 
subsistema de vídeo de SDL. Sin embargo, el resto de componentes de SDL no se ven 
afectados por esta cuestión. 


La instalación de SDL en sistemas Debian y derivados es trivial mediante los siguien- 
tes comandos: 


$ sudo apt-get update 

$ sudo apt-get install libsdl1.2-dev 

$ sudo apt-get install libsdl-imagel.2-dev 

$ sudo apt-get install libsdl-sound1.2-dev libsdl-mixerl.2-dev 





2GLUT fue concebido para utilizarse en un entorno más académico, simplificando el tratamiento de eventos 
y la gestión de ventanas. 
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Para generar un fichero ejecutable, simplemente es necesario enlazar con las bibliote- 
cas necesarias. 


Listado 6.12: Ejemplo sencillo SDL + OpenGL. 


1 include <SDL/SDL.h> 

2 ttinclude <GL/gl.h> 

3 *tinclude <stdio.h> 

4 

5 int main (int argc, char x*argv[]) ( 

6 SDL_Surface x*screen; 

7 // Inicialización de SDL. 

8 if (SDL_Init(SDL_INIT_VIDEO) != 0) 4 

9 fprintf(stderr, "Unable to initialize SDL: *sXn", 


10 SDL_GetError()); 
11 return -1; 

12 J 

13 


14 // Cuando termine el programa, llamada a SQLQuit(). 

15 atexit(SDL_Quit); 

16 // Activación del double buffering. 

17 SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1); 

18 

19 // Establecimiento del modo de vídeo con soporte para OpenGL. 
20 screen = SDL_SetVideoMode(640, 480, 16, SDL_OPENGL); 

21 if (screen == NULL) X 


22 fprintf(stderr, "Unable to set video mode: *sXn", 
23 SDL_GetError()); 

24 return -1; 

25 J 

26 

27 SDL_wWM_SetCaption("OpenGL with SDL!", "OpenGL"); 


28 // ¡Ya es posible utilizar comandos OpenGL! 

29 glViewport(80, 0, 480, 480); 

30 

31 glMatrixMode(GL_PROJECTION) ; 

32 glLoadIdentity(); 

33 glFrustum(-1.0, 1.0, -1.0, 1.0, 1.0, 100.0); 

34 glClearColor(1, 1, 1, 0); 

35 

36 glMatrixMode(GL_MODELVIEW); glLoadIdentity(); 

37 glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); 

38 

39 // Renderizado de un triángulo. 

40 glBegin(GL_TRIANGLES); 

41 glColor3f(1.0, 0.0, 0.0); glVertex3f(0.0, 1.0, -2.0); 
42 glColor3f(0.0, 1.0, 0.0); glVertex3f(1.0, -1.0, -2.0); 
43 glColor3f(0.0, 0.0, 1.0); glVertex3f(-1.0, -1.0, -2.0); 
44 glEnd(); 

45 

46 glFlush(); 

47 SDL_GL_SwapBuffers(); // Intercambio de buffers. 


48 SDL_Delay(5000); // Espera de 5 seg. 
49 

50 return 0; 

51 y 


Como se puede apreciar en el listado anterior, la línea (20) establece el modo de vídeo 
con soporte para OpenGL para, posteriormente, hacer uso de comandos OpenGL a partir 
de la línea (29). Sin embargo, note cómo el intercambio del contenido entre el front buffer 
y el back buffer se realiza en la línea (47) mediante una primitiva de SDL. 
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Listado 6.13: Ejemplo de Makefile para integrar SDL. 


1 CFLAGS := -c -Wall 
2 LDFLAGS := “*sdl-config --cflags --libs* -1SDL_image -1GL 





3 LDLIBS := -1SDL_image -1GL 

4 CC := gcc 

5 

6 all: basic_sdl_opengl 

7 

8 basic_sdl_opengl: basic_sdl_opengl.o 
9 $(CC) $(LDFLAGS) -o $4 $7 $(LDLIBS) 
10 

11 basic_sdl_opengl.o: basic_sdl_opengl.c 
12 $(CC) $(CFLAGS) $” -o $8 

13 

14 clean: 

15 fecho Cleaning up... 

16 rm -f *- x*.0 basic_sdl_opengl 

17 (echo Done. 

13 


19 vclean: clean 


Reproducción de música 


En esta sección se discute cómo implementar? un nuevo recurso que permita la re- 
producción de archivos de música dentro de un juego. En este ejemplo se hará uso de la 
biblioteca SDL_mixer para llevar a cabo la reproducción de archivos de sonido*. 


En primer lugar se define una clase Track que será utilizada para gestionar el recurso 
asociado a una canción. Como ya se ha comentado anteriormente, esta clase hereda de 
la clase Ogre::Resource, por lo que será necesario implementar las funciones necesarias 
para el nuevo tipo de recurso. Además, se incluirá la funcionalidad típica asociada a una 
canción, como las clásicas operaciones play, pause o stop. El siguiente listado de código 
muestra la declaración de la clase Track. 


Listado 6.14: Clase Track. 


1 *tinclude <SDL/SDL_mixer.h> 

2 Htinclude <0OGRE/Ogre.h> 

3 

4 class Track : public Ogre::Resource ( 

5 public: 

6 // Constructor (ver Ogre: :Resource). 

7 Track (Ogre: :ResourceManager* pManager, 
8 const Ogre: :Stringú resource_name, 


9 Ogre: :ResourceHandle handle, 

10 const Ogre: :Stringú resource_group, 

11 bool manual_load = false, 

12 Ogre: :ManualResourceLoaderx* pLoader = 0); 
13 Track (); 

14 


15 // Manejo básico del track. 
16 void play (int loop = -1); 
17 void pause (); 
18 void stop (); 





3La implementación de los recursos de sonido está basada en el artículo titulado Extender la gestión de 
recursos, audio del portal IberOgre, el cual se encuentra disponible en http://0s12.uca.es/iberogre/index. 
php/Extender_la_gestión_de_recursos,_audio. 

4SDL_mixer sólo permite la reproducción de un clip de sonido de manera simultánea, por lo que no será 
posible realizar mezclas de canciones. 
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void fadeln (int ms, int loop); 
void fade0ut (int ms); 
static bool isPlaying (); 


private: 
25 // Funcionalidad de Ogre: :Resource. 
2 void loadImpl (); 
2 void unloadImpl (); 

size_t calculateSize () const; 


// Variables miembro. 

Mix_Musicx _pTrack; // SDL 

Ogre: :String _path; // Ruta al track. 
size_t _size; // Tamaño. 


$; 


El constructor de esta clase viene determinado por la 
especificación del constructor de la clase Ogre::Resource. 
De hecho, su implementación delega directamente en el 
constructor de la clase padre para poder instanciar un re- 
curso, además de inicializar las propias variables miem- 
bro. 


Por otra parte, las funciones de manejo básico del 
track (líneas (16-22) son en realidad una interfaz para ma- 
nejar de una manera adecuada la biblioteca SDL_mixer. 


Por ejemplo, la función miembro play simplemente 
interactúa con SDL para comprobar si la canción estaba 
pausada y, en ese caso, reanudarla. Si la canción no es- 
taba pausada, entonces dicha función la reproduce desde 





Figura 6.12: Es posible incluir efec- 
tos de sonidos más avanzados, como 
por ejemplo reducir el nivel de volu- 
men a la hora de finalizar la repro- 
ducción de una canción. 


el principio. Note cómo se hace uso del gestor de logs de Ogre3D para almacenar en un 


archivo la posible ocurrencia de algún tipo de error. 


void 

Track: :play 
(int loop) 
1 


Ogre: :LogManager* pLogManager = 
Ogre: :LogManager: :getSingletonPtr(); 


if(Mix_PausedMusic()) // Estaba pausada? 
Mix _ResumeMusic();  // Reanudación. 


// Si no, se reproduce desde el principio. 


else ( 
if (Mix PlayMusic(_pTrack, loop) == -1) 4 
pLogManager->logMessage("Track: :play() Error al...."); 


throw (Ogre: :Exception(Ogre::Exception::ERR_FILE_NOT_FOUND, 


"Imposible reproducir...", 
7 "Track: :play()")); 
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Dos de las funciones más importantes de cualquier tipo de recurso que extienda de 
Ogre::Resource son loadImpl() y unloadImpl(), utilizadas para cargar y liberar el recurso, 
respectivamente. Obviamente, cada tipo de recurso delegará en la funcionalidad necesaria 
para llevar a cabo dichas tareas. En el caso de la gestión básica del sonido, estas funciones 
delegarán principalmente en SDL_mixer. A continuación se muestra el código fuente de 
dichas funciones. 


Debido a la necesidad de manejar de manera eficiente los recursos de sonido, la solu- 
ción discutida en esta sección contempla la definición de punteros inteligentes a través de 
la clase TrackPtr. La justificación de esta propuesta, como ya se introdujo anteriormente, 
consiste en evitar la duplicidad de recursos, es decir, en evitar que un mismo recurso esté 
cargado en memoria principal más de una vez. 


Listado 6.16: Clase Track. Funciones loadImpl() y unloadImpl(. 


void 
Track: :loadImpl () // Carga del recurso. 
t 


1 
2 
3 
4 // Ruta al archivo. 

5 Ogre: :FileInfoListPtr info; 

6 info = Ogre: :ResourceGroupManager: :getSingleton(). 
7 findResourceFileInfo(mGroup, mName)'; 

8 

9 


for (Ogre::FileInfoList::const_iterator i = info->begin(); 


10 i != info->end(); ++i) £ 

11 _path = i->archive->getName() + "/" + ¡i->filename; 
12 , 

13 

14 if (_path == "") 4  // Archivo no encontrado... 
15 // Volcar en el log y lanzar excepción. 

16 , 

17 

18 // Cargar el recurso de sonido. 

19 if ((_pTrack = Mix_LoadMUS(_path.c_str())) == NULL) 4 
20 // Si se produce un error al cargar el recurso, 
21 // volcar en el log y lanzar excepción. 

22 , 

23 

24 // Cálculo del tamaño del recurso de sonido. 

25 “size =... 

26 y 

27 

28 void 

29 Track: :unloadImpl() 

30 £ 

31 if (_pTrack) £ 

32 // Liberar el recurso de sonido. 

33 Mix_FreeMusic(_pTrack); 

34 , 

35 ) 


Ogre3D permite el uso de punteros inteligentes compartidos, definidos en la clase 
Ogre::SharedPtr, con el objetivo de parametrizar el recurso definido por el desarrollador, 
por ejemplo Track, y almacenar, internamente, un contador de referencias a dicho recurso. 
Básicamente, cuando el recurso se copia, este contador se incrementa. Si se destruye 
alguna referencia al recurso, entonces el contador se decrementa. Este esquema permite 
liberar recursos cuando no se estén utilizando en un determinado momento y compartir 
un mismo recurso entre varias entidades. 
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El listado de código 6.17 muestra la implementación de la clase TrackPtr, la cual in- 
cluye una serie de funciones (básicamente constructores y asignador de copia) heredadas 
de Ogre::SharedPtr. A modo de ejemplo, también se incluye el código asociado al cons- 
tructor de copia. Como se puede apreciar, en él se incrementa el contador de referencias 
al recurso. 


Listado 6.17: Clase TrackPtr y constructor de copia. 


1 // Smart pointer a Track. 

2 class TrackPtr: public Ogre: :SharedPtr<Track> ( 

3 public: 

4 // Es necesario implementar constructores y operador de asignación. 
5  TrackPtr(): Ogre::SharedPtr<Track>() (7 

6 explicit TrackPtr(Track* m): Ogre::SharedPtr<Track>(m) () 

7  TrackPtr(const TrackPtr £m): Ogre: :SharedPtr<Track>(m) () 

8  TrackPtr(const Ogre: :ResourcePtr €r); 

9  TrackPtrú operator= (const Ogre: :ResourcePtrá r); 

10 >; 


12 TrackPtr::TrackPtr 

13 (const Ogre: :ResourcePtr Gresource): Ogre: :SharedPtr<Track>() 4 
14 // Comprobar la validez del recurso. 

15 if (resource.isNull()) 

16 return; 


18 // Para garantizar la exclusión mutua... 
19 OGRE_LOCK_MUTEX(*resource.OGRE_AUTO_MUTEX_NAME) 
20 OGRE_COPY_AUTO_SHARED_MUTEX(resource.OGRE_AUTO_MUTEX_NAME) 


22 pRep = static_cast<Track*x>(resource.getPointer()); 
23 pUseCount = resource.useCountPointer(); 
24 useFreeMethod = resource.freeMethod(); 


25 

26 // Incremento del contador de referencias. 
27 if (pUseCount) 

28 ++(*pUseCount); 

29 ) 


Una vez implementada la lógica necesaria para instanciar y manejar recursos de so- 
nido, el siguiente paso consiste en definir un gestor o manager específico para centralizar 
la administración del nuevo tipo de recurso. Ogre3D facilita enormemente esta tarea gra- 
cias a la clase Ogre::ResourceManager. En el caso particular de los recursos de sonido se 
define la clase TrackManager, cuyo esqueleto se muestra en el listado de código 6.18. 


Esta clase no sólo hereda del gestor de recursos de Ogre, sino que también lo hace 
de la clase Ogre::Singleton con el objetivo de manejar una única instancia del gestor de 
recursos de sonido. Las funciones más relevantes son las siguientes: 


= load() (líneas (19-11), que permite la carga de canciones por parte del desarrolla- 
dor. Si el recurso a cargar no existe, entonces lo creará internamente utilizando la 
función que se comenta a continuación. 


= createlmpl() (líneas (18-23), función que posibilita la creación de un nuevo recurso, 
es decir, una nueva instancia de la clase Track. El desarrollador es responsable de 
realizar la carga del recurso una vez que ha sido creado. 
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Listado 6.18: Clase TrackManager. Funciones load() y createlmpl(). 


1 
2 
3 
4 


wo Jou 


10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 


// Clase encargada de gestionar recursos del tipo "Track". 
// Funcionalidad heredada de Ogre: :ResourceManager 
// y Ogre: :Singleton. 
class TrackManager: public Ogre: :ResourceManager, 
public Ogre: :Singleton<TrackManager> f 
public: 
TrackManager(); 
virtual —TrackManager(); 
// Función de carga genérica. 
virtual TrackPtr load (const Ogre::Stringá name, 
const Ogre: :Stringé group); 
static TrackManager8 getSingleton (); 
static TrackManagerx getSingletonPtr (); 


protected: 
// Crea una nueva instancia del recurso. 
Ogre: :Resourcex createlmpl (const Ogre: :Strings name, 
Ogre: :ResourceHandle handle, 
const Ogre: :Stringá group, 
bool isManual, 
Ogre: :ManualResourceLoaderx loader, 
const Ogre: :NameValuePairListx* createParams); 


y; 


TrackPtr 
TrackManager: :load 
(const Ogre::Strings name, const Ogre: :Stringé group) 
t 
// Obtención del recurso por nombre... 
TrackPtr trackPtr = getByName (name) ; 


// Si no ha sido creado, se crea. 
if (trackPtr.isNull()) 
trackPtr = create(name, group); 


// Carga explícita del recurso. 
trackPtr->load(); 


return trackPtr; 


// Creación de un nuevo recurso. 
Ogre: :Resourcex 
TrackManager: :createImpl (const Ogre::Stringé resource_name, 
Ogre: :ResourceHandle handle, 
const Ogre: :Stringú resource_group, 
bool isManual, 
Ogre: :ManualResourceLoaderx loader, 
const Ogre: :NameValuePairListx* createParams) 


return new Track(this, resource_name, handle, 
resource_group, isManual, loader); 
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Con las tres clases que se han discutido en esta sección ya es posible realizar la carga 
de recursos de sonido, delegando en la biblioteca SDL_mixer, junto con su gestión y ad- 
ministración básicas. Este esquema encapsula la complejidad del tratamiento del sonido, 
por lo que en cualquier momento se podría sustituir dicha biblioteca por otra. 


Más adelante se muestra un ejemplo concreto en el que se hace uso de este tipo de 
recursos sonoros. Sin embargo, antes de discutir este ejemplo de integración se planteará 
el soporte de efectos de sonido, los cuales se podrán mezclar con el tema o track principal 
a la hora de desarrollar un juego. Como se planteará a continuación, la filosofía de diseño 
es exactamente igual que la planteada en esta sección. 


Soporte de efectos de sonido 


Además de llevar a cabo la reproducción del algún tema musical durante la ejecución 
de un juego, la incorporación de efectos de sonido es esencial para alcanzar un buen grado 
de inmersión y que, de esta forma, el jugador se sienta como parte del propio juego. Desde 
un punto de vista técnico, este esquema implica que la biblioteca de desarrollo permita la 
mezcla de sonidos. En el caso de SDL_mixer es posible llevar a cabo dicha integración. 


Como se ha comentado anteriormente, a efectos de implementación, la integración 
de efectos de sonidos (FX effects) sigue el mismo planteamiento que el adoptado para la 
gestión básica de sonido. Para ello, en primer lugar se han creado las clases SoundFX 
y SoundFXPtr, con el objetivo de gestionar y manipular las distintas instancias de los 
efectos de sonido, respectivamente. En el siguiente listado de código se muestra la cla- 
se SoundFX, que se puede entender como una simplificación de la clase Track, ya que 
los efectos de sonido se reproducirán puntualmente, mediante la función miembro play, 
cuando así sea necesario. 


La manipulación de efectos de sonido se centraliza en la clase SoundFXManager, 
la cual implementa el patrón Singleton y hereda de la clase Ogre::ResourceManager. La 
diferencia más sustancial con respecto al gestor de sonido reside en que el tipo de recurso 
mantiene un identificador textual distinto y que, en el caso de los efectos de sonido, se 
lleva a cabo una reserva explícita de 32 canales de audio. Para ello, se hace uso de una 
función específica de la biblioteca SDL_mixer. 


class SoundFX: public Ogre: :Resource 4 
public: 
// Constructor (ver Ogre: :Resource). 
SoundFX(Ogre::ResourceManagerx* creator, 
// Igual que en Track... 
Y; 
-SoundFX(); 


int play(int loop = 0); // Reproducción puntual. 


protected: 

void loadImpl(); 

void unloadImpl(); 

size_t calculateSize() const; 


private: 

Mix_Chunkx _pSound; // Info sobre el efecto de sonido. 
Ogre: :String _path; // Ruta completa al efecto de sonido. 
size _t _size; // Tamaño del efecto (bytes). 


$; 
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Figura 6.13: Diagrama simplificado de clases de las principales entidades utilizadas para llevar a cabo la inte- 


gración de música y efectos de sonido. 


Integrando música y efectos 


Para llevar a cabo la integración de los aspectos básicos previamente discutidos sobre 
la gestión de música y efectos de sonido se ha tomado como base el código fuente de la 
sesión de iluminación del módulo 2, Programación Gráfica. En este ejemplo se hacía uso 
de una clase MyFrameListener para llevar a cabo la gestión de los eventos de teclado. 





Figura 6.14: Captura de pantalla de 
la ejecución del ejemplo de la sesión 
de iluminación del módulo 2, Pro- 
gramación Gráfica. 


Por una parte, este ejemplo se ha extendido para in- 
cluir la reproducción ininterrumpida de un tema musical, 
es decir, un tema que se estará reproduciendo desde que 
se inicia la aplicación hasta que ésta finaliza su ejecución. 
Por otra parte, la reproducción de efectos de sonido adi- 
cionales está vinculada a la generación de ciertos eventos 
de teclado. En concreto, cada vez que el usuario pulsa las 
teclas *1” 6 ”2”, las cuales están asociadas a dos esquemas 
diferentes de cálculo del sombreado, la aplicación repro- 
ducirá un efecto de sonido puntual. Este efecto de sonido 
se mezclará de manera adecuada con el track principal. 


El siguiente listado de código muestra la nueva fun- 
ción miembro introducida en la clase MyApp para realizar 
la carga de recursos asociada a la biblioteca SDL_mixer. 


Listado 6.20: Clase MyApp. Función initSDL() 


1 bool 
2 MyApp::initSDL () 4 


4 // Inicializando SDL... 

5 if (SDL_Init(SDL_INIT_AUDIO) < 0) 

6 return false; 

7 // Llamar a SDL_Quit al terminar. 

8 atexit(SDL_Quit); 

9 

10 // Inicializando SDL mixer... 

11 if (Mix_OpenAudio(MIX_DEFAULT_FREQUENCY, MIX_DEFAULT_FORMAT, 
12 MIX_DEFAULT_CHANNELS, 4096) < 0) 
13 return false; 

14 

15 // Llamar a Mix_CloseAudio al terminar. 
16 atexit(Mix_CloseAudio); 

17 

18 return true; 
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Es importante resaltar que a la hora de arrancar la instancia de la clase MyApp me- 
diante la función start(), los gestores de sonido y de efectos se instancian. Además, se 
lleva a cabo la reproducción del track principal. 


Listado 6.21: Clase MyApp. Función start() 


1 // SE OMITE PARTE DEL CÓDIGO FUENTE. 
2 int 
3 MyApp: :start() £ 


4 
5 _root = new Ogre: :Root(); 

6 —_pTrackManager = new TrackManager; 

7 —pSoundFXManager = new SoundFXManager; 
8 

9 // Window, cámara y viewport... 

10 


11 loadResources(); 
12 createScene(); 
13 create0verlay(); 


15 // FrameListener... 


17 // Reproducción del track principal... 
18 this->_mainTrack->play(); 


19 

20 _root->startRendering(); 
21 return 0; 

22 y 


Finalmente, sólo hay que reproducir los eventos de sonido cuando así sea necesario. 
En este ejemplo, dichos eventos se reproducirán cuando se indique, por parte del usuario, 
el esquema de cálculo de sombreado mediante las teclas ”1” ó ”2”. Dicha activación se 
realiza, por simplificación, en la propia clase FrameListener; en concreto, en la función 


miembro frameStarted a la hora de capturar los eventos de teclado. 


Listado 6.22: Clase MyApp. Función frameStarted() 


1 // SE OMITE PARTE DEL CÓDIGO FUENTE. 

2 

3 bool 

4 MyFrameListener::frameStarted 

5 (const Ogre: :FrameEventé evt) ( 

6 

7 —keyboard->capture(); 

8 // Captura de las teclas de fecha... 

9 

10 if(_keyboard->isKeyDown(0IS::KC_1)) 4 

11 _sceneManager->setShadowTechnique(Ogre: : SHADOWTYPE_TEXTURE_MODULATIVE); 
12 _shadowInfo = "TEXTURE_MODULATIVE"; 

13 _pMyApp->getSoundFXPtr()->play();  // REPRODUCCIÓN. 
14 , 

15 

16 if(_keyboard->isKeyDown(01IS::KC_2)) 4 

17 _sceneManager->setShadowTechnique(Ogre: : SHADOWTYPE_STENCIL_MODULATIVE); 
18 _shadowInfo = "STENCIL_MODULATIVE"; 

19 _pMyApp->getSoundFXPtr()->play();  // REPRODUCCIÓN. 
20 

21 


22 // Tratamiento del resto de eventos... 
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El esquema planteado para la gestión de sonido mantiene la filosofía de delegar el 
tratamiento de eventos de teclado, al menos los relativos a la parte sonora, en la clase 
principal (MyApp). Idealmente, si la gestión del bucle de juego se plantea en base a un 
esquema basado en estados, la reproducción de sonido estaría condicionada por el estado 
actual. Este planteamiento también es escalable a la hora de integrar nuevos estados de 
juegos y sus eventos de sonido asociados. La activación de dichos eventos dependerá no 
sólo del estado actual, sino también de la propia interacción por parte del usuario. 


6.3. El sistema de archivos 


El gestor de recursos hace un uso extensivo del sistema de archivos. Típicamente, 
en los PCs los sistemas de archivos son accesibles mediante llamadas al sistema, propor- 
cionadas por el propio sistema operativo. Sin embargo, en el ámbito de los motores de 
juegos se suelen plantear esquemas más generales y escalables debido a la diversidad de 
plataformas existente para la ejecución de un juego. 


Esta idea, discutida anteriormente a lo largo del curso, se basa en hacer uso de wrap- 
pers o de capas software adicionales para considerar aspectos clave como el desarrollo 
multiplataforma. El planteamiento más común consiste en envolver la API del sistema de 
archivos con una API específica del motor de juegos con un doble objetivo: 


= En el desarrollo multiplataforma, esta API específica proporciona el nivel de abs- 
tracción necesario para no depender del sistema de archivos y de la plataforma 
subyacente. 


= La API vinculada al sistema de archivos puede no proporcionar toda la funcionali- 
dad necesaria por el motor de juegos. En este caso, la API específica complementa 














a la nativa. 

Por ejemplo, la mayoría de sistemas operativos no 
proporcionan mecanismos para cargar datos on the fly 
/ mientras un juego está en ejecución. Por lo tanto, el mo- 
tor de juegos debería ser capaz de soportar streaming de 

ficheros. 
| tone] LA] [seda Por otra parte, cada plataforma de juegos maneja un 
sistema de archivos distinto e incluso necesita gestionar 
distintos dispositivos de entrada/salida (E/S), como por 














david || tus | | andrea ejemplo discos blu-ray o tarjetas de memoria. Esta varie- 
dad se puede ocultar gracias al nivel extra de abstracción 


Figura 6.15: Generalmente, los sis- proporcionado por la API del propio motor de juegos. 
temas de archivos mantienen estruc- 
turas de árbol o de grafo. 


6.3.1. Gestión y tratamiento de archivos 


El sistema de archivos define la organización de los 

datos y proporciona mecanismos para almacenar, recupe- 

rar y actualizar información. Así mismo, también es el encargado de gestionar el espacio 

disponible en un determinado dispositivo de almacenamiento. Idealmente, el sistema de 

archivos ha de organizar los datos de una manera eficiente, teniendo en cuenta incluso las 
características específicas del dispositivo de almacenamiento. 


En el ámbito de un motor de juegos, la API vinculada a la gestión del sistema de 
archivos proporciona la siguiente funcionalidad [5]: 
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Figura 6.16: Jerarquía típica del sistema de archivos UNIX. 


Manipular nombres de archivos y rutas. 


Abrir, cerrar, leer y escribir sobre archivos. 


Listar el contenido de un directorio. 


Manejar peticiones de archivos de manera asíncrona. 


Una ruta o path define la localización de un determinado archivo o directorio y, nor- 
malmente, está compuesta por una etiqueta que define el volumen y una serie de compo- 
nentes separados por algún separador, como por ejemplo la barra invertida. En sistemas 
UNIX, un ejemplo típico estaría representado por la siguiente ruta: 


/home/david/apps/firefox/firefox-bin 


En el caso de las consolas, las rutas suelen seguir un convenio muy similar incluso para 
referirse a distintos volúmenes. Por ejemplo, PlayStation3"Mutiliza el prefijo /dev_bdvd 
para referirse al lector de blu-ray, mientras que el prefijo /dev_hddx permite el acceso a 
un determinado disco duro. 


Las rutas o paths pueden ser absolutas o relativas, en función de si están definidas 
teniendo como referencia el directorio raíz del sistema de archivos u otro directorio, res- 
pectivamente. En sistemas UNIX, dos ejemplos típicos serían los siguientes: 


/usr/share/doc/ogre-doc/api/html/index.html 
apps/firefox/firefox-bin 


El primero de ellos sería una ruta absoluta, ya que se define en base al directorio raíz. 
Por otra parte, la segunda sería una ruta relativa, ya que se define en relación al directorio 
/home/david. 


Antes de pasar a discutir aspectos de la gestión de E/S, resulta importante comentar 
la existencia de APIs específicas para la gestión de rutas. Aunque la gestión básica de 
tratamiento de rutas se puede realizar mediante cadenas de texto, su complejidad hace 
necesaria, normalmente, la utilización de APIs específicas para abstraer dicha compleji- 
dad. La funcionalidad relevante, como por ejemplo la obtención del directorio, nombre 
y extensión de un archivo, o la conversión entre paths absolutos y relativos, se puede 
encapsular en una API que facilite la interacción con este tipo de componentes. 
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Encapsulación. Una vez más, el principio de encapsulación resulta fundamental 
uy para abstraerse de la complejidad asociada al tratamiento del sistema de archivos 
y del sistema operativo subyacente. 











En el caso del desarrollo de videojuegos multiplataforma, se suele hacer uso de otra 
API adicional para envolver a las APIs específicas para el tratamiento de archivos en 
diversos sistemas operativos. 


Caso de estudio. La biblioteca Boost.Filesystem 


En el contexto de APIs específicas para la gestión de rutas, el uso de la biblioteca 
Boost.Filesystem? es un ejemplo representativo de API multiplataforma para el trata- 
miento de rutas en C++. Dicha biblioteca es compatible con el estándar de C++, es 
portable a diversos sistemas operativos y permite el manejo de errores mediante excep- 
ciones. 


El siguiente listado de código muestra un programa que realiza un procesamiento 
recursivo de archivos, mostrando su nombre independientemente del tipo de archivo (re- 
gular o directorio). Como se puede apreciar, con un programa trivial es posible llevar a 
cabo tareas básicas para el tratamiento de rutas. 


Listado 6.23: Ejemplo de uso de boost::filesystem. 


ttinclude <iostream> 
*tinclude <boost/filesystem.hpp> 


1 
2 
3 
4 using namespace std; 

5 using namespace boost: :filesystem; 
6 

7 

8 

9 


void list_directory (const pathá dir, const intá tabs); 


int main (int argc, charx argv[]) £ 
10 if (argc< 2) £ 


11 cout << "Uso: ./exec/Simple <path>" << endl; 

12 return 1; 

13 , 

14 path p(argv[1]); // Instancia de clase boost: :path. 
15 

16 if (is regular_file(p)) 

17 cout << " "<<p<<" "<<file_ size(p) << " B" << endl; 
18 else if (is directory(p)) // Listado recursivo. 

19 list_directory(p, 0); 

20 

21 return 0; 

22 y 

23 

24 void 


25 print_tabs (const intá tabs) £ 
26 for (int i=0; i< tabs; ++1) cout << "Mt"; 
27 y 


29 void list_directory 

30 (const pathá p, const inté tabs) £ 

31 vector<path> paths; 

32 // directory iterator para iterar sobre los contenidos del dir. 
33 copy (directory_iterator(p), directory_iterator(), 


34 back_inserter(paths)); 
35 sort(paths.begin(), paths.end()); // Se fuerza el orden. 
36 





Swww.boost.org/libs/filesystem/ 
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// Pretty print ;-) 
for (vector<path>::const_iterator it = paths.begin(); 
it != paths.end(); ++it) 4 
if (is directory(*it)) 4 
print_tabs(tabs); 
cout << xit << endl; 
list_directory(x*it, (tabs + 1)); 


else if (is regular_file(*it)) £ 
print_tabs(tabs); 
cout << (*it) << 
, 
, 
) 


<< file _size(x*it) << " B" << endl; 





La instalación de la biblioteca Boost. Filesystem en sistemas Debian y derivados es 
uy trivial mediante cualquier gestor de paquetes. Una búsqueda con apt-cache search es 
todo lo que necesitas para averiguar qué paquete/s hay que instalar. 











6.3.2. E/S básica 


Para conseguir que la E/S asociada a un motor de juegos sea eficiente, resulta im- 
prescindible plantear un esquema de memoria intermedia que permita gestionar tanto los 
datos escritos (leídos) como el destino en el que dichos datos se escriben (leen). Típi- 
camente, la solución a este problema está basada en el uso de buffers. Básicamente, un 
buffer representa un puente de comunicación entre el propio programa y un archivo en 
disco. En lugar de, por ejemplo, realizar la escritura byte a byte en un archivo de texto, 
se suelen emplear buffers intermedios para reducir el número de escrituras en disco y, de 
este modo, mejorar la eficiencia de un programa. 


En esta sección se prestará especial atención a Stream 1/0 API 
la biblioteca estándar de C, ya que es la más co- La APLdS HIS con bale que propor 
múnmente utilizada para llevar a cabo la gestión de ciona la biblioteca estándar de C se de- 
E/S en el desarrollo de videojuegos. nomina comúnmente Stream YO API, 


El 1 sd ¡e . debido a que proporciona una abstrac- 
enguaje de programación € permite mane- ción que permite gestionar los archivos 


jar dos APIs para gestionar las operaciones más re- en disco como flujos de bytes. 

levantes en relación al contenido de un archivo, co- 

mo la apertura, lectura, escritura o el cierre. La primera de ellas proporciona E/S con 
buffers mientras que la segunda no. 


La diferencia entre ambas reside en que la API con E/S mediante buffer gestiona de 
manera automática el uso de los propios buffers sin necesidad de que el programador 
asuma dicha responsabilidad. Por el contrario, la API de C que no proporciona E/S con 
buffers tiene como consecuencia directa que el programador ha de asignar memoria para 
dichos buffers y gestionarlos. La tabla 6.1 muestra las principales operaciones de dichas 
APIs. 
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Htinclude <stdio.h> 


int lectura_sincrona (const charx* archivo, charx* buffer, 
size_t tamanyo_buffer, size_tx* p_bytes_leidos); 


int main (int argc, const char* argv[]) 4 


char buffer[256]; 
size_t bytes_leidos = 0; 


if (lectura_sincrona("test.txt", buffer, sizeof(buffer), €bytes_leidos)) 
printf("*%i bytes leidos!in", bytes _leidos); 


return 0; 


) 


int lectura_sincrona (const charx archivo, charx buffer, 
size_t tamanyo_buffer, size_tx* p_bytes_leidos) 4 


FILEx manejador = NULL; 


if ((manejador = fopen(archivo, "rb"))) 4 
// Llamada bloqueante en fread, 
// hasta que se lean todos los datos. 
size_t bytes_leidos = fread(buffer, 1, tamanyo_buffer, manejador); 


// Ignoramos errores... 
fclose(manejador); 


*p_bytes_leidos = bytes_leidos; 


return 1; 


) 


return -1; 


) 


Dependiendo del sistema operativo en cuestión, las invocaciones sobre operaciones 
de E/S se traducirán en llamadas nativas al sistema operativo, como ocurre en el caso de 
UNIX y variantes, o en envolturas sobre alguna otra API de más bajo nivel, como es el 
caso de sistemas Microsoft Windows'M, Es posible aprovecharse del hecho de utilizar 
las APIs de más bajo nivel, ya que exponen todos los detalles de implementación del 


sistema de archivos nativo [5]. 
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Figura 6.17: El uso de invocaciones 
síncronas tiene como consecuencia 
el bloqueo de la entidad que realiza 
la invocación. 


Una opción relevante vinculada al uso de buffers con- 
siste en gestionarlos para reducir el impacto que la gene- 
ración de archivos de log produce. Por ejemplo, se puede 
obtener un resultado más eficiente si antes de volcar in- 
formación sobre un archivo en disco se utiliza un buffer 
intermedio. Así, cuando éste se llena, entonces se vuelca 
sobre el propio archivo para mejorar el rendimiento de la 
aplicación. En este contexto, se puede considerar la dele- 
gación de esta tarea en un hilo externo al bucle principal 
del juego. 


En relación a lo comentado anteriormente sobre el uso 
de APIs de más bajo nivel, surge de manera inherente la 
cuestión relativa al uso de envolturas o wrappers sobre la 


propia biblioteca de E/S, ya sea de bajo nivel y dependiente del sistema operativo o de más 
alto nivel y vinculada al estándar de C. Comúnmente, los motores de juegos hacen uso de 
algún tipo de capa software que sirva como envoltura de la API de E/S. Este planteamiento 
proporcionar tres ventajas importantes [5]: 
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API E/S con buffers 





Operación 


Signatura 





Abrir archivo 
Cerrar archivo 


FILE *fopen(const char *path, const char *mode); 
int fclose(FILE *fp); 





Leer archivo 


Escribir archivo 


size_t fread(void *ptr, size_t size, size_t nmemb, FILE 
*stream); 

size_t fwrite(const void *ptr, size_t size, size_t nmemb, 
FILE *stream); 





Desplazar 
Obtener offset 


int fseek(FILE *stream, long offset, int whence); 
long ftell(FILE *stream); 





Lectura línea 
Escritura línea 


char *fgets(char *s, int size, FILE *stream); 
int fputs(const char *s, FILE *stream); 





Lectura cadena 
Escritura cadena 


int fscanf(FILE *stream, const char *format, ...); 
int fprintf(FILE *stream, const char *format, ...); 





Obtener estado 


int fstat(int fd, struct stat *buf); 


API ESS sin buffers 





Operación 


Signatura 





Abrir archivo 
Cerrar archivo 


int open(const char *pathname, int flags, mode_t mode); 
int close(int £d); 





Leer archivo 
Escribir archivo 


ssize_t read(int fd, void *buf, size_t count); 
ssize_t write(int fd, const void *buf, size_t count); 











Desplazar off_t lseek(int fd, off_t offset, int whence); 
Obtener offset off_t tell(int £d); 

Lectura línea No disponible 

Escritura línea No disponible 

Lectura cadena No disponible 

Escritura cadena | No disponible 





Obtener estado 





int stat(const char *path, struct stat *buf); 


Tabla 6.1: Resumen de las principales operaciones de las APIs de C para la gestión de E/S (con y sin 
buffers). 


1. Es posible garantizar que el comportamiento del motor en distintas plataformas 
sea idéntico, incluso cuando la biblioteca nativa de más bajo nivel presente algún 
tipo de cuestión problemática. 


2. Es posible adaptar la API de más alto nivel a las necesidades del motor de jue- 
gos. De este modo, se mejora la mantenibilidad del mismo ya que sólo se presta 
atención a los aspectos del sistema de E/S realmente utilizados. 


3. Es un esquema escalable que permite integrar nueva funcionalidad, como por ejem- 
plo la necesidad de tratar con dispositivos de almacenamiento externos, como uni- 
dades de DVD o Blu-Ray. 


Finalmente, es muy importante tener en cuenta que las bibliotecas de E/S estándar de 
C son síncronas. En otras palabras, ante una invocación de E/S, el programa se queda 
bloqueado hasta que se atiende por completo la petición. El listado de código anterior 
muestra un ejemplo de llamada bloqueante mediante la operación fread(). 
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Evidentemente, el esquema síncrono presenta un inconveniente muy importante, ya 
que bloquea al programa mientras la operación de E/S se efectúa, degradando así el ren- 
dimiento global de la aplicación. Un posible solución a este problema consiste en adoptar 
un enfoque asíncrono, tal y como se discute en la siguiente sección. 


6.3.3. E/S asíncrona 


La E/S asíncrona gira en torno al concepto de streaming, el cual se refiere a la carga 
de contenido en un segundo plano, es decir, mientras el programa principal está en un 
primer plano de ejecución. Este esquema posibilita la carga de contenido en tiempo de 
ejecución, es decir, permite obtener contenido que será utilizado en un futuro inmediato 
por la propia aplicación, evitando así potenciales cuellos de botella y garantizando que la 
tasa por segundos del juego no decaiga. 


Normalmente, cuando un juego se ejecuta, se hace uso tanto del disco duro como de 
algún tipo de dispositivo de almacenamiento externo, como por ejemplo unidades ópti- 


cas, para cargar contenido audiovisual en la memoria principal. Últimamente, uno de los 
esquemas más utilizados, incluso en consolas de sobremesa, consiste en instalar el juego 
en el disco duro a partir de la copia física del juego, que suele estar en DVD o Blu-Ray. 
Este proceso consiste en almacenar determinados elementos del juego en el disco duro 
con el objetivo de agilizar los tiempos de carga en memoria principal. 


El uso del disco duro permite la carga de elementos en segundo plano mientras el 
juego continúa su flujo de ejecución normal. Por ejemplo, es perfectamente posible cargar 
las texturas que se utilizarán en el siguiente nivel mientras el jugador está terminando el 
nivel actual. De este modo, el usuario no se desconecta del juego debido a cuestiones 
externas. 


Para implementar este esquema, la E/S asíncrona resulta fundamental, ya que es una 
aproximación que permite que el flujo de un programa no se bloquee cuando es necesario 
llevar a cabo una operación de E/S. En realidad, lo que ocurre es que el flujo del pro- 
grama continúa mientras se ejecuta la operación de E/S en segundo plano. Cuando ésta 
finaliza, entonces notifica dicha finalización mediante una función de retrollamada. Las 
funciones de retrollamada se suelen denominar comúnmente callbacks. Este concepto no 
sólo se usa en el ámbito de la E/S asíncrona, sino también en el campo de los sistemas 
distribuidos y los middlewares de comunicaciones. 


La figura 6.18 muestra de manera gráfica cómo dos agentes se comunican de manera 
asíncrona mediante un objeto de retrollamada. Básicamente, el agente notificador envía 
un mensaje al agente receptor de manera asíncrona. Esta invocación tiene dos parámetros: 
1) el propio mensaje m y ii) un objeto de retrollamada cb. Dicho objeto será usado por el 
agente receptor cuando éste termine de procesar el mensaje. Mientras tanto, el agente 
notificador continuará su flujo normal de ejecución, sin necesidad de bloquearse por el 
envío del mensaje. 


La mayoría de las bibliotecas de E/S asíncrona existentes permiten que el progra- 
ma principal espera una cierta cantidad de tiempo antes de que una operación de E/S se 
complete. Este planteamiento puede ser útil en situaciones en las que los datos de dicha 
operación se necesitan para continuar con el flujo normal de trabajo. Otras APIs pueden 
proporcionar incluso una estimación del tiempo que tardará en completarse una opera- 
ción de E/S, con el objetivo de que el programador cuente con la mayor cantidad posible 
de información. Así mismo, también es posible encontrarse con operaciones que asignen 
deadlines sobre las propias peticiones, con el objetivo de plantear un esquema basado 
en prioridades. Si el deadline se cumple, entonces también suele ser posible asignar el 
código a ejecutar para contemplar ese caso en particular. 
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Figura 6.18: Esquema gráfico representativo de una comunicación asíncrona basada en objetos de retrollamada. 


Desde un punto de vista general, la E/S asíncrona se suele implementar mediante hilos 
auxiliares encargados de atender las peticiones de E/S. De este modo, el hilo principal 
ejecuta funciones que tendrán como consecuencia peticiones que serán encoladas para 
atenderlas posteriormente. Este hilo principal retornará inmediatamente después de llevar 
a cabo la invocación. 


El hilo de E/S obtendrá la siguiente petición de la cola y la atenderá utilizando fun- 
ciones de E/S bloqueantes, como la función fread discutida en el anterior listado de có- 
digo. Cuando se completa una petición, entonces se invoca al objeto o a la función de 
retrollamada proporcionada anteriormente por el hilo principal (justo cuando se realizó la 
petición inicial). Este objeto o función notificará la finalización de la petición. 


En caso de que el hilo principal tenga que esperar a que la petición de E/S se complete 
antes de continuar su ejecución será necesario proporcionar algún tipo de mecanismo 
para garantizar dicho bloqueo. Normalmente, se suele hacer uso de semáforos [14] (ver 
figura 6.20), vinculando un semáforo a cada una de las peticiones. De este modo, el hilo 
principal puede hacer uso de wait hasta que el hilo de E/S haga uso de signal, posibilitando 
así que se reanude el flujo de ejecución. 


6.3.4. Caso de estudio. La biblioteca Boost.Asio C++ 


Boost.Asioó es una biblioteca multiplataforma desa- 
rrollada en C++ con el objetivo de dar soporte a operacio- 
nes de red y de E/S de bajo nivel a través de un modelo 6 
asíncrono consistente y bajo un enfoque moderno. Asio GS b oost 
se enmarca dentro del proyecto Boost. j 


23: oe Figura 6.19: Las bibliotecas del 
El desarrollo de esta biblioteca se justifica por la ne- proyecto Boost representan, general- 


cesidad de interacción entre programas, ya sea mediante mente, una excelente alternativa pa- 
ficheros, redes o mediante la propia consola, que no pue- ra solucionar un determinado proble- 
den quedarse a la espera ante operaciones de E/S cuyo Ma. 





Shttp ://think-async.com/Asio/ 
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tiempo de ejecución sea elevado. En el caso del desarro- 

llo de videojuegos, una posible aplicación de este enfoque, tal y como se ha introducido 
anteriormente, sería la carga en segundo plano de recursos que serán utilizados en el fu- 
turo inmediato. La situación típica en este contexto sería la carga de los datos del siguiente 
nivel de un determinado juego. 


Según el propio desarrollador de la biblioteca”, Asio 
proporciona las herramientas necesarias para manejar es- 
te tipo de problemática sin la necesidad de utilizar, por 
parte del programador, modelos de concurrencia basa- 
dos en el uso de hilos y mecanismos de exclusión mutua. 
Aunque la biblioteca fue inicialmente concebida para la 
problemática asociada a las redes de comunicaciones, és- 
ta es perfectamente aplicable para llevar a cabo una E/S 
asíncrona asociada a descriptores de ficheros o incluso a 
puertos serie. 


Los principales objetivos de diseño de Boost.Asio 
son los siguientes: 


= Portabilidad, gracias a que está soportada en un 
amplio rango de sistemas operativos, proporcio- 
nando un comportamiento consistente en los mis- 
mos. 


= Escalabilidad, debido a que facilita el desarrollo 
de aplicaciones de red que escalen a un gran nú- 
mero de conexiones concurrentes. En principio, la 
implementación de la biblioteca en un determinado 
sistema operativo se beneficia del soporte nativo de 
éste para garantizar esta propiedad. 


= Eficiencia, gracias a que la biblioteca soporta as- 
pectos relevantes, como por ejemplo la reducción 
de las copias de datos. 


= Reutilización, debido a que Asio se basa en mode- 
los y conceptos ya establecidos, como la API BSD 





Socket. 
Figura 6.20: Esquema general de Eon a A 
uso de un semáforo para controlar el = Facilidad de uso, ya que la biblioteca está orienta- 
acceso a determinadas secciones de da a proporcionar un kit de herramientas, en lugar 


Sueliga. de basarse en el modelo framework. 

La instalación de la biblioteca Boost.Asio en sistemas 
Debian y derivados es trivial mediante los siguientes co- 
mandos: 


$ sudo apt-get update 
$ sudo apt-get install libasio-dev 





Thttp ://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio.html 
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A continuación se plantean algunos ejemplos ya implementados con el objetivo de 
ilustrar al lector a la hora de plantear un esquema basado en el asincronismo para, por 
ejemplo, llevar a cabo operaciones de E/S asíncrona o cargar recursos en segundo plano*. 
El siguiente listado muestra un programa de uso básico de la biblioteca Asio, en el que se 
muestra la consecuencia directa de una llamada bloqueante. 


*tinclude <iostream> 
*tinclude <boost/asio.hpp> 
*tinclude <boost/date_time/posix_time/posix_time.hpp> 


int main () € 
// Todo programa que haga uso de asio ha de instanciar 
// un objeto del tipo io service para manejar la E/S. 
boost: :asio::io_service io; 


// Instancia de un timer (3 seg.) 
// El primer argumento siempre es un io service. 
boost: :asio::deadline_timer t(io, boost::posix_time: :seconds(3)); 


// Espera explícita. 
t.wait(); 


std::cout << "Hola Mundo!" << std: :endl; 


return 0; 


Para compilar, enlazar y generar el archivo ejecutable, simplemente es necesario eje- 
cutar las siguientes instrucciones: 


$ g++ Simple.cpp -o Simple -lboost_system -lboost_date_time 
$ ./Simple 


En determinados contextos resulta muy deseable llevar a cabo una espera asíncrona, 
es decir, continuar ejecutando instrucciones mientras en otro nivel de ejecución se reali- 
zan otras tareas. Si se utiliza la biblioteca Boost.Asio, es posible definir manejadores de 
código asociados a funciones de retrollamada que se ejecuten mientras el programa con- 
tinúa la ejecución de su flujo principal. Asio también proporciona mecanismos para que 
el programa no termine mientras haya tareas por finalizar. 


El listado de código 6.26 muestra cómo el ejemplo anterior se puede modificar para 
llevar a cabo una espera asíncrona, asociando en este caso un temporizador que controla 
la ejecución de una función de retrollamada. 


La ejecución de este programa generará la siguiente salida: 


$ Esperando a print()... 
$ Hola Mundo! 


Sin embargo, pasarán casi 3 segundos entre la impresión de una secuencia y otra, ya 
que inmediatamente después de la llamada a la espera asíncrona (línea (15)) se ejecutará 
la primera secuencia de impresión (línea (7), mientras que la ejecución de la función de 
retrollamada print() (líneas (6-8)) se demorará 3 segundos. 





La noción de segundo plano en este contexto está vinculada a independizar ciertas tareas de la ejecución 
del flujo principal de un programa. 
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Listado 6.26: Biblioteca Asio. Espera asíncrona. 


1 *Hinclude <iostream> 

2 *tinclude <boost/asio.hpp> 

3 *tinclude <boost/date_time/posix_time/posix_time.hpp> 
4 

5 // Función de retrollamada. 

6 void print (const boost::system::error_codes e) ( 

7 std::cout << "Hola Mundo!" << std: :endl; 

8) 

9 

10 int main () € 

11 boost: :asio::io_service io; 

12 

13 boost: :asio::deadline_timer t(io, boost::posix_time: :seconds(3)); 
14 // Espera asíncrona. 

15 t.async_wait(8print); 





16 
17 std::cout << "Esperando a print()..." << std: :endl; 
18 // Pasarán casi 3 seg. hasta que print se ejecute... 
19 


20 // io.run() para garantizar que los manejadores se llamen desde 
21 // hilos que llamen a run(). 

22 // run() se ejecutará mientras haya cosas por hacer, 

23 // en este caso la espera asíncrona a print. 

24 io.run(); 

25 

26 return 0; 

27 y 


Otra opción imprescindible a la hora de gestionar estos manejadores reside en la po- 
sibilidad de realizar un paso de parámetros, en función del dominio de la aplicación que 
se esté desarrollando. El siguiente listado de código muestra cómo llevar a cabo dicha 
tarea. 


Listado 6.27: Biblioteca Asio. Espera asíncrona y paso de parámetros. 





1 fdefine THRESHOLD 5 


3 // Función de retrollamada con paso de parámetros. 

4 void count (const boost::system: :error_codeú e, 

5 boost: :asio::deadline_timerx* t, intx* counter) ( 
6 if (x*counter < THRESHOLD) 4 

7 std::cout << "Contador... " << x*counter << std: :endl; 
8 ++(x*counter); 


9 

10 // El timer se prolonga un segundo... 

11 t->expires_at(t->expires_at() + boost: :posix_time::seconds(1)); 
12 // Llamada asíncrona con paso de argumentos. 

13 t->async_wait(boost::bind 

14 (count, boost: :asio::placeholders::error, t, counter)); 
15 , 

16 y 

17 

18 int main () € 

19 int counter = 0; 


20 boost: :asio::deadline_timer t(io, boost::posix_time: :seconds(1)); 
21 // Llamada inicial. 
22 t.async_wait(boost::bind 


23 (count, boost: :asio::placeholders::error, 
24 €t, Gcounter)); 
25 1 O 


26 ) 
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Como se puede apreciar, las llamadas a la función async_wait() varían con respecto 
a otros ejemplos, ya que se indica de manera explícita los argumentos relevantes para la 
función de retrollamada. En este caso, dichos argumentos son la propia función de retro- 
llamada, para realizar llamadas recursivas, el timer para poder prolongar en un segundo su 
duración en cada llamada, y una variable entera que se irá incrementando en cada llamada. 


Flexibilidad en Asio La biblioteca Boost.Asio también permite en- 
Ta hiblotess Boosc Ago es ie capsular las funciones de retrollamada que se eje- 
xible y posibilita la llamada asíncro- cutan de manera asíncrona como funciones miem- 
na a una función que acepta un núme- bro de una clase. Este esquema mejora el diseño 
ro arbitrario de parámetros. Éstos pue- de la aplicación y permite que el desarrollador se 
den ser variables, punteros, o funcio- abstraiga de la implementación interna de la clase. 


eS) SnHTe OHos. El siguiente listado de código muestra una posible 


modificación del ejemplo anterior mediante la de- 
finición de una clase Counter, de manera que la función count pasa a ser una función 
miembro de dicha clase. 


class Counter 4 
public: 
Counter (boost::asio::io_services io) 
: _timer(io, boost: :posix_time::seconds(1)), _count(0) £ 
_timer.async_wait(boost::bind(SCounter: :count, this)); 


J 


Counter () £ cout << "Valor final: " << _count << endl; $ 


void count () £ 
if (_count < 5) X£ 
std::cout << _count++ << std::endl; 
_timer.expires_at(_timer.expires_at() + 
boost: :posix_time::seconds(1)); 
// Manejo de funciones miembro. 
_timer.async_wait(boost::bind(€Counter::count, this)); 


) 
) 
private: 
boost: :asio::deadline_timer _timer; 
int _count; 


$; 


int main () € 
boost::asio::io_service io; 
Counter c(io); // Instancia de la clase Counter. 
2 io.run(); 
return 0; 


En el contexto de carga de contenido en un juego de manera independiente al hilo de 
control principal, el ejemplo anterior no serviría debido a que presenta dos importantes 
limitaciones. Por una parte, la respuesta de la función de retrollamada no es controlable si 
dicha retrollamada tarda mucho tiempo en completarse. Por otra parte, este planteamiento 
no es escalable a sistemas multiproceso. 


Para ello, una posible solución consiste en hacer uso de un pool de hilos que inter- 
actúen con ¡o_service::run(). Sin embargo, este esquema plantea un nuevo problema: la 
necesidad de sincronizar el acceso concurrente de varios manejadores a los recursos com- 
partidos, como por ejemplo una variable miembro de una clase. 


El siguiente listado de código extiende la definición de la clase Counter para manejar 
de manera concurrente dos timers que irán incrementado la variable miembro _count. 
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En este caso, la biblioteca proporciona wrappers para envolver las funciones de retro- 
llamada count! y count2, con el objetivo de que, internamente, Asio controle que dichos 
manejadores no se ejecutan de manera concurrente. En el ejemplo propuesto, la variable 
miembro _count no se actualizará, simultáneamente, por dichas funciones miembro. 


Listado 6.29: Biblioteca Asio. Espera asíncrona y clases. 


1 class Counter ( 
2 public: 
3 Counter (boost::asio::io_services io) 


4 : _strand(io), // Para garantizar la exclusión mutua. 
5 _timerl(io, boost::posix_time: :seconds(1)), 

6 _timer2(io, boost: :posix_time: :seconds(1)), 

7 _count(0) X£ 

8 // Los manejadores se 'envuelven' por strand para 
9 // que no se ejecuten de manera concurrente. 

10 _timerl.async_wait(_strand.wrap 

11 (boost: :bind(S£Counter::count1, this))); 
12 _timer2.async_wait(_strand.wrap 

13 (boost: :bind(S£Counter::count2, this))); 
14 , 

15 


16 // count1 y count2 nunca se ejecutarán en paralelo. 
17 void count1() 4 


18 if (_count < 10) £ 

19 // IDEM que en el ejemplo anterior. 

20 _timerl.async_wait(_strand.wrap 

21 (boost: :bind(4£Counter::count1, this))); 
22 

23 , 

24 


25 // IDEM que countl pero sobre timer2 y count2 
26 void count2() ( /* src */ $ 


28 private: 

29 boost: :asio::strand _strand; 

30 boost: :asio::deadline_timer _timerl, _timer2; 
31 int _count; 

32 y; 


34 int main() € 

35 boost: :asio::io_service io; 

36 // run() se llamará desde dos threads (principal y boost) 

37 Counter c(io); 

38 boost: :thread t(boost::bind(áboost::asio::io service::run, €io)); 
39 io.run(); 

40 t.join(); 


42 return 0; 


También resulta interesante destacar la instanciación de un hilo adicional a través de la 
clase boost::thread, de manera que la función ¡o_service::run() se llame tanto desde este 
hilo como desde el principal. La filosofía de trabajo se mantiene, es decir, los hilos se se- 
guirán ejecutando mientras haya trabajo pendiente. En concreto, el hilo en segundo plano 
no finalizará hasta que todas las operaciones asíncronas hayan terminado su ejecución. 
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6.3.5. Consideraciones finales 


En el siguiente capítulo se discutirá otro enfoque basado en la concurrencia mediante 
hilos en C++ para llevar a cabo tareas como por ejemplo la carga de contenido, en segundo 
plano, de un juego. En dicho capítulo se utilizará como soporte la biblioteca de utilida- 
des del middleware ZeroC ICE, el cual también se estudiará en el módulo 3, Técnicas 
Avanzadas de Desarrollo. 


6.4. Importador de datos de intercambio 


En esta sección se justifica la necesidad de plantear esquemas de datos para impor- 
tar contenido desde entornos de creación de contenido 3D, como por ejemplo Blender. 
Aunque existen diversos estándares para la definición de datos multimedia, en la práctica 
cada aplicación gráfica interactiva tiene necesidades específicas que han de cubrirse con 
un software particular para importar dichos datos. 


Por otra parte, el formato de los datos es otro aspecto relevante, existiendo distintas 
aproximaciones para codificar la información multimedia a importar. Uno de los esque- 
mas más utilizados consiste en hacer uso del metalenguaje XML (eXtensible Markup 
Language), por lo que en este capítulo se discutirá esta opción en detalle. XML mantiene 
un alto nivel semántico, está bien soportado y estandarizado y permite asociar estructuras 
de árbol bien definidas para encapsular la información relevante. Además, posibilita que 
el contenido a importar sea legible por los propios programadores. 


Es importante resaltar que este capítulo está centrado en la parte de importación de 
datos hacia el motor de juegos, por lo que el proceso de exportación no se discutirá a 
continuación (sí se hará, no obstante, en el módulo 2 de Programación Gráfica). 


6.4.1. Formatos de intercambio 


La necesidad de intercambiar información es una constante no sólo entre los dis- 
tintos componentes de un motor de juegos, sino también entre entornos de creación de 
contenido 3D y el propio motor. El modelado y la animación de personajes y la creación 
de escenarios se realiza mediante este tipo de suites de creación 3D para, posteriormen- 
te, integrarlos en el juego. Este planteamiento tiene como consecuencia la necesidad de 
abordar un doble proceso (ver figura 6.21) para llevar a cabo la interacción entre las partes 
implicadas: 


1. Exportación, con el objetivo de obtener una representación de los datos 3D. 


2. Importación, con el objetivo de acceder a dichos datos desde el motor de juegos o 
desde el propio juego. 


En el caso particular de Ogre3D, existen diversas herramientas? que posibilitan la 
exportación de datos a partir de un determinado entorno de creación de contenido 3D, 
como por ejemplo Blender, 3DS Max, Maya o Softimage, entre otros. El proceso inverso 
también se puede ejecutar haciendo uso de herramientas como OgreXmlConverter', que 
permiten la conversión entre archivos .mesh y .skeleton a ficheros XML y viceversa. 


El proceso de importación en Ogre3D está directamente relacionado con el formato 
XML a través de una serie de estructuras bien definidas para manejar escenas, mallas o 
esqueletos, entre otros. 





2 http: //ww.ogre3d.org/tikiwiki/OGRE+Exporters 
http ://www.ogre3d.org/tikiwiki/OgreXmlConverter 
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Figura 6.21: Procesos de importanción y exportación de datos 3D haciendo uso de documentos XML. 


Aunque el uso del metalenguaje XML es una de las opciones más extendidas, a conti- 
nuación se discute brevemente el uso de otras alternativas. 


Archivos binarios 


El mismo planteamiento discutido que se usa para llevar a cabo el almacenamiento 
de las variables de configuración de un motor de juegos, utilizando un formato binario, 
se puede aplicar para almacenar información multimedia con el objetivo de importarla 
posteriormente. 


Este esquema basado en un formato binario es muy eficiente y permite hacer uso 
de técnicas de serialización de objetos, que a su vez incrementan la portabilidad y la 
sencillez de los formatos binarios. En el caso de hacer uso de orientación a objetos, la 
funcionalidad necesaria para serializar y de-serializar objetos se puede encapsular en la 
propia definición de clase. 


Es importante destacar que la serialización de objetos puede generar información en 
formato XML, es decir, no tiene por qué estar ligada a un formato binario. 


Archivos en texto plano 


El uso de archivos en texto plano es otra posible alternativa a la hora de importar 
datos. Sin embargo, esta aproximación tiene dos importantes desventajas: 1) resulta menos 
eficiente que el uso de un formato binario e ii) implica la utilización de un procesador de 
texto específico. 


En el caso de utilizar un formato no estandarizado, es necesario explicitar los separa- 
dores o tags existentes entre los distintos campos del archivo en texto plano. Por ejemplo, 
se podría pensar en separadores como los dos puntos, el punto y coma y el retorno de 
carro para delimitar los campos de una determinada entidad y una entidad de la siguiente, 
respectivamente. 


XML 


EXtensible Markup Language (XML) se suele definir como un metalenguaje, es de- 
cir, como un lenguaje que permite la definición de otros lenguajes. En el caso particular 
de este capítulo sobre datos de intercambio, XML se podría utilizar para definir un len- 
guaje propio que facilite la importación de datos 3D al motor de juegos o a un juego en 
particular. 


Actualmente, XML es un formato muy popular debido a los siguientes motivos: 


= Es un estándar. 


= Está muy bien soportado, tanto a nivel de programación como a nivel de usuario. 
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= Es legible. 


= Tiene un soporte excelente para estructuras de datos jerárquicas; en concreto, de 
tipo arbóreas. Esta propiedad es especialmente relevante en el dominio de los vi- 


deojuegos. 


Sin embargo, no todo son ventajas. El proceso de par- 
seado o parsing es relativamente lento. Esto implica que 
algunos motores hagan uso de formatos binarios propie- 
tarios, los cuales son más rápidos de parsear y mucho 
más compactos que los archivos XML, reduciendo así los 
tiempos de importación y de carga. 


El parser Xerces-C++ 


Como se ha comentado anteriormente, uno de los mo- 
tivos por los que XML está tan extendido es su amplio 
soporte a nivel de programación. En otras palabras, prác- 
ticamente la mayoría de lenguajes de programación pro- 
porcionan bibliotecas, APIs y herramientas para procesar 
y generar contenidos en formato XML. 


En el caso del lenguaje C++, estándar de facto en la 
industria del videojuego, el parser Xerces-C++!! es una 
de las alternativas más completas para llevar a cabo el 
procesamiento de ficheros XML. En concreto, esta he- 
rramienta forma parte del proyecto Apache XML, el cual 
gestiona un número relevante de subproyectos vinculados 
al estándar XML. 


Xerces-C++ está escrito en un subconjunto portable 
de C++ y tiene como objetivo facilitar la lectura y escri- 
tura de archivos XML. Desde un punto de vista técnico, 
Xerces-C++ proporciona una biblioteca con funcionali- 
dad para parsear, generar, manipular y validar documen- 
tos XML utilizando las APIs DOM, SAX (Simple API for 
XML) y SAX2. Estas APIs son las más populares para 
manipular documentos XML y difieren, sin competir en- 
tre sí, en aspectos como el origen, alcance o estilo de pro- 
gramación. 





Figura 6.22: Visión conceptual de la 
relación de XML con otros lenguajes. 





Figura 6.23: La instalación de pa- 
quetes en sistemas Debian también 
se puede realizar a través de gestores 
de más alto nivel, como por ejemplo 
Synaptic. 


Por ejemplo, mientras DOM (Document Object Model) está siendo desarrollada por el 
consorcio W3, SAX (Simple API for XML) no lo está. Sin embargo, la mayor diferencia 
reside en el modelo de programación, ya que SAX presenta el documento XML como 
una cadena de eventos serializada, mientras que DOM lo trata a través de una estructura 
de árbol. La principal desventaja del enfoque planteado en SAX es que no permite un 
acceso aleatorio a los elementos del documento. No obstante, este enfoque posibilita que 
el desarrollador no se preocupe de información irrelevante, reduciendo así el tamaño en 


memoria necesario por el programa. 


La instalación de Xerces-C++, incluyendo documentación y ejemplos de referencia, 
en sistemas Debian y derivados es trivial mediante los siguientes comandos: 


$ sudo apt-get update 

$ sudo apt-get install libxerces-c-dev 
$ sudo apt-get install libxerces-c-doc 
$ sudo apt-get install libxerces-samples 





Mhttp ://xerces.apache.org/xerces-Cc/ 
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Desde un punto de vista general, se recomienda el uso de DOM en proyectos en los 
que se vayan a integrar distintos componentes de código y las necesidades funciona- 

y les sean más exigentes. Por el contrario, SAX podría ser más adecuado para flujos de 
trabajo más acotados y definidos. 











6.4.2. Creación de un importador 


Justificación y estructura XML 


En esta sección se discute el diseño e implementación de un importador específico 
para un juego muy sencillo titulado NoEscapeDemo, el cual hará uso de la biblioteca 
Xerces-C++ para llevar a cabo la manipulación de documentos XML. 


Básicamente, el juego consiste en interactuar con una serie de wumpus o fantasmas 
que aparecen de manera automática en determinados puntos de un escenario y que des- 
aparecen en otros. La interacción por parte del usuario consiste en modificar el compor- 
tamiento de dichos fantasmas cambiando, por ejemplo, el sentido de navegación de los 
mismos. 


La figura 6.24 muestra, desde un punto de vista abstracto, la representación del esce- 
nario en el que los fantasmas habitan. Como se puede apreciar, la representación interna 
de dicho escenario es un grafo, el cual define la navegabilidad de un punto en el espacio 
3D a otro. En el grafo, algunos de los nodos están etiquetados con los identificadores S o 
D, representando puntos de aparición y desaparición de fantasmas. 


El contenido gráfico de esta sencilla demo está compuesto de los siguientes elementos: 


= El propio escenario tridimensional, considerando los puntos o nodos de generación 
y destrucción de fantasmas. 


= Los propios fantasmas. 


= Una o más cámaras virtuales, que servirán para visualizar el juego. Cada cámara 
tendrá asociado un camino o path, compuesto a su vez por una serie de puntos clave 
que indican la situación (posición y rotación) de la cámara en cada momento. 


El nodo raíz En principio, la información del escenario y de 
La etiqueta <data> es el nodo raíz del las ea pe do eos hs l e ha- 
documento XML. Sus posibles nodos ciendo uso del importador cuyo diseño se discute 
hijo están asociados con las etiquetas a continuación. Sin embargo, antes se muestra un 
<graph> y <camera>. posible ejemplo de la representación de estos me- 


diante el formato definido para la demo en cuestión. 


En concreto, el siguiente listado muestra la parte de información asociada a la estruc- 
tura de grafo que conforma el escenario. Como se puede apreciar, la estructura graph está 
compuesta por una serie de vértices (vertex) y de arcos (edge). 


Por una parte, en los vértices del grafo se in- 


Vértices y arcos A E E 
cluye su posición en el espacio 3D mediante las 


En el formato definido, los vértices se 


identifican a través del atributo index. etiquetas <x>, <y> y <z>. Además, cada vértice 
Estos IDs se utilizan en la etiqueta tiene como atributo un índice, que lo identifica uní- 
<edge> para especificar los dos vérti- vocamente, y un tipo, el cual puede ser spawn (pun- 
ces que conforman un arco. to de generación) o drain (punto de desaparición), 


respectivamente. Por otra parte, los arcos permiten 
definir la estructura concreta del grafo a importar mediante la etiqueta <vertex>. 
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Figura 6.24: Representación interna bidimensional en forma de grafo del escenario de NoEscapeDemo. Los 
nodos de tipo S (spawn) representan puntos de nacimiento, mientras que los nodos de tipo D (drain) representan 
sumideros, es decir, puntos en los que los fantasmas desaparecen. 


Listado 6.30: Ejemplo de fichero XML usado para exportar e importar contenido asociado al grafo 





del escenario. 


1 <?xml version='1.0' encoding='UTF-8'?> 


2 <data> 

3 

4 <graph> 

5 

6 <vertex index="1" type="spawn"> 

7 <x>1.5</x> <y>2.5</y> <z>-3</Z> 

8 </vertex> 

9 <!-- More vertexes... --> 

10 <vertex index="4" type="drain"> 

11 <x>1.5</x> <y>2.5</y> <z>-3</Z> 

12 </vertex> 

13 

14 <edge> 

15 <vertex>1</vertex> <vertex>2</vertex> 
16 </edge> 

17 <edge> 

18 <vertex>2</vertex> <vertex>4</vertex> 
19 </edge> 

20 <!-- More edges... --> 

21 

22 </graph> 

23 

24 <!-- Definition of virtual cameras --> 
25 </data> 


En caso de que sea necesario incluir más contenido, simplemente habrá que extender 
el formato definido. XML facilita enormemente la escalabilidad gracias a su esquema 
basado en el uso de etiquetas y a su estructura jerárquica. 
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El siguiente listado muestra la otra parte de la estructura del documento XML utilizado 
para importar contenido. Éste contiene la información relativa a las cámaras virtuales. 
Como se puede apreciar, cada cámara tiene asociado un camino, definido con la etiqueta 
<path>, el cual consiste en una serie de puntos o frames clave que determinan la anima- 
ción de la cámara. 


Cada punto clave del camino de una cámara contiene la posición de la misma en el 
espacio 3D (etiqueta <frame>) y la rotación asociada, expresada mediante un cuaternión 
(etiqueta <rotation>). 


Listado 6.31: Ejemplo de fichero XML usado para exportar e importar contenido asociado a las 


cámaras virtuales. 





1 <?xml version='1.0' encoding="UTF-8'?> 
2  <data> 
3 <!-- Graph definition here--> 


4 
5 <camera index="1" fps="25"> 

6 

7 <path> 

8 

9 <frame index="1"> 

10 <position> 

11 <x>1.5</x> <y>2.5</y> <z>-3</z> 
12 </position> 

13 <rotation> 

14 <x>0.17</x> <y>0.33</y> <z>0.33</Z> <w>0.92</w> 
15 </rotation> 

16 </frame> 

17 

18 <frame index="2"> 

19 <position> 

20 <x>2.5</x> <y>2.5</y> <z>-3</z> 
21 </position> 

22 <rotation> 

23 <x>0.17</x> <y>0.33</y> <z>0.33</Z> <w>0.92</w> 
24 </rotation> 

25 </frame> 

26 

27 <!-- More frames here... --> 
28 

29 </path> 

30 

31 </camera> 

32 

33 <!-- More cameras here... --> 

34 </data> 


Lógica de dominio 


La figura 6.25 muestra el diagrama de las principales clases vinculadas al importador 
de datos. Como se puede apreciar, las entidades más relevantes que forman parte del 
documento XML se han modelado como clases con el objetivo de facilitar no sólo la 
obtención de los datos sino también su integración en el despliegue final con Ogre3D. 
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La clase que centraliza la lógica de dominio es la clase Scene, la cual mantiene una re- 
lación de asociación con las clases Graph y Camera. Recuerde que el contenido a importar 
más relevante sobre el escenario era la estructura de grafo del mismo y la información de 
las cámaras virtuales. La encapsulación de los datos importados de un documento XML 
se centraliza en la clase Scene, la cual mantiene como estado un puntero a un objeto de 
tipo Graph y una estructura con punteros a objetos de tipo Camera. El listado de código 
6.32 muestra la declaración de la clase Scene. 


Listado 6.32: Clase Scene. 


*tinclude <vector> 
*tinclude <Camera.h> 
*tinclude <Node.h> 
*tinclude <Graph.h> 


class Scene 
t 
public: 
Scene (); 
10 -Scene (); 
11 
12 void addCamera (Camerax* camera); 
13 Graphx* getGraph () £ return _graph;) 
14 std: :vector<Camera*> getCameras () [ return _cameras; ) 


a 
2 
3 
4 
5 
6 
7 
8 
9 


16 private: 

17 Graph x_graph; 

18 std: :vector<Camerax> _cameras; 
19 >; 


Por otra parte, la clase Graph mantiene la lógica de gestión básica para implementar 
una estructura de tipo grafo mediante listas de adyacencia. El siguiente listado de código 
muestra dicha clase e integra una función miembro para obtener la lista de vértices o 
nodos adyacentes a partir del identificador de uno de ellos (línea (27). 


Listado 6.33: Clase Graph. 


1 *tinclude <iostream> 

2 ftinclude <vector> 

3 *tinclude <GraphVertex.h> 
4 Htinclude <GraphEdge.h> 

5 

6 class Graph £ 


7 public: 

8 Graph (); 

9 -Graph (); 
10 


11 void addVertex (GraphVertexx* pVertex); 
12 void addEdge (GraphVertex* pOrigin, GraphVertexx* pDestination, 
13 bool undirected = true); 


15 // Lista de vértices adyacentes a uno dado. 
16 std: :vector<GraphVertexx*> adjacents (int index); 


18 GraphVertex* getVertex (int index); 
19 std: :vector<GraphVertexx*> getVertexes () const 


20 [return _vertexes;) 
21 std: :vector<GraphEdgex> getEdges () const ( return _edges; ) 
22 


23 private: 

24 std: :vector<GraphVertex*> _vertexes; 
25 std: :vector<GraphEdgex> _edges; 

26 y; 
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Figura 6.25: Diagrama de clases de las entidades más relevantes del importador de datos. 


Las clases GraphVertex y GraphEdge no se mostrarán ya que son relativamente 
triviales. Sin embargo, resulta interesante resaltar la clase Node, la cual contiene infor- 
mación relevante sobre cada uno de los vértices del grafo. Esta clase permite generar 
instancias de los distintos tipos de nodos, es decir, nodos que permiten la generación y 
destrucción de los fantasmas de la demo planteada. La clase GraphVertex mantiene como 
variable de clase un objeto de tipo Node, el cual alberga la información de un nodo en el 
espacio 3D. 


// SE OMITE PARTE DEL CÓDIGO FUENTE. 
class Node 
f 
public: 
Node (); 
Node (const inté index, const stringú type, 
const Ogre: :Vector348 pos); 


Node (); 

int getIndex () const [ return _index; $ 

string getType () const [ return _type; ) 

Ogre: :Vector3 getPosition () const [ return _position; ) 
private: 

int _index; // Índice del nodo (id único) 

string _type; // Tipo: generador (spawn), sumidero (drain) 
Ogre: :Vector3 _position; // Posición del nodo en el espacio 3D 


y; 


Respecto al diseño de las cámaras virtuales, las clases Camera y Frame son las utili- 
zadas para encapsular la información y funcionalidad de las mismas. En esencia, una cá- 
mara consiste en un identificador, un atributo que determina la tasa de frames por segundo 
a la que se mueve y una secuencia de puntos clave que conforman el camino asociado a 
la cámara. 
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La clase Importer 


El punto de interacción entre los datos contenidos en el documento XML y la lógi- 
ca de dominio previamente discutida está representado por la clase Importer. Esta clase 
proporciona la funcionalidad necesaria para parsear documentos XML con la estruc- 
tura planteada anteriormente y rellenar las estructuras de datos diseñadas en la anterior 
sección. 


El siguiente listado de código muestra la declaración de la clase Importer. Como se 
puede apreciar, dicha clase hereda de Ogre::Singleton para garantizar que solamente exis- 
te una instancia de dicha clase, accesible con las funciones miembro getSingleton() y 
getSingletonPtr()?. 


Note cómo, además de estas dos funciones miembro, la única función miembro públi- 
ca es parseScene() (línea (9)), la cual se puede utilizar para parsear un documento XML 
cuya ruta se especifica en el primer parámetro. El efecto de realizar una llamada a esta 
función tendrá como resultado el segundo parámetro de la misma, de tipo puntero a ob- 
jeto de clase Scene, con la información obtenida a partir del documento XML (siempre y 
cuando no se produzca ningún error). 


Listado 6.35: Clase Importer. 


1 *tinclude <0GRE/Ogre.h> 
2 Htinclude <xercesc/dom/DOM.hpp> 
3 ¿Htinclude <Scene.h> 


4 
5 class Importer: public Ogre: :Singleton<Importer> ( 

6 public: 

7 // Única función miembro pública para parsear. 

8 void parseScene (const charx path, Scene x*scn); 

9 

10 static Importerá getSingleton (); // Ogre: :Singleton. 
11 static Importer* getSingletonPtr ();  // Ogre: :Singleton. 
12 


13 private: 

14 // Funcionalidad oculta al exterior. 

15: // Facilita el parseo de las diversas estructuras 

16 // del documento XML. 

17 void parseCamera (xercesc::DOMNodex cameraNode, Scenex scn); 
18 

19 void addPathToCamera (xercesc::DOMNodex pathNode, Camera *cam); 
20 void getFramePosition (xercesc::DOMNodex* node, 


21 Ogre: :Vector3x position); 
22 void getFrameRotation (xercesc: :DOMNodex* node, 
23 Ogre: :Vector4x* rotation); 
24 


25 void parseGraph (xercesc::DOMNodex* graphNode, Scenex scn); 
26 void addVertexToScene (xercesc::DOMNodex* vertexNode, Scenex scn); 
27 void addEdgeToScene (xercesc::DOMNodex edgeNode, Scenex scn); 


29 // Función auxiliar para recuperar valores en punto flotante 
30 // asociados a una determinada etiqueta (tag). 
31 float getValueFromTag (xercesc::DOMNodex node, const XMLCh x*tag); 


El código del importador se ha estructurado de acuerdo a la definición del propio do- 
cumento XML, es decir, teniendo en cuenta las etiquetas más relevantes dentro del mismo. 
Así, dos de las funciones miembro privadas relevantes son, por ejemplo, las funciones par- 
seCamera() y parseGraph(), usadas para procesar la información de una cámara virtual y 
del grafo que determina el escenario de la demo. 





12Se podría haber desligado la implementación del patrón Singleton y Ogre3D. 
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La biblioteca Xerces-C++ hace uso de tipos de datos específicos para, por ejemplo, 
manejar cadenas de texto o los distintos nodos del árbol cuando se hace uso del API 
DOM. De hecho, el API utilizada en este importador es DOM. El siguiente listado de 
código muestra cómo se ha realizado el procesamiento inicial del árbol asociado al docu- 
mento XML. El árbol generado por el API DOM a la hora de parsear un documento XML 
puede ser costoso en memoria. En ese caso, se podría plantear otras opciones, como por 
ejemplo el uso del API SAX. 


Aunque se ha omitido gran parte del código, incluido el tratamiento de errores, el 
esquema de procesamiento representa muy bien la forma de manejar este tipo de docu- 
mentos haciendo uso del API DOM. Básicamente, la idea general consiste en obtener 
una referencia a la raíz del documento (líneas (13-14) y, a partir de ahí, ir recuperando la 
información contenida en cada uno de los nodos del mismo. 


El bucle for (líneas (20-21)) permite recorrer los nodos hijo del nodo raíz. Si se detecta 
un nodo con la etiqueta <camera>, entonces se llama a la función miembro parseCame- 
ra(). Si por el contrario se encuentra la etiqueta <graph>, entonces se llama a la función 
parseGraph(). En ambos casos, estas funciones irán poblando de contenido el puntero a 
objeto de tipo Scene que se pasa como segundo argumento. 


// SE OMITE PARTE DEL CÓDIGO FUENTE (bloques try-catch) 

void Importer::parseScene (const charx* path, Scene x*scene) 4 
// Inicialización. 
XMLPlatformUtils::Initialize(); 


XercesDOMParserx parser = new XercesDOMParser(); 
parser->parse(path); 


DOMDocumentx* xmlDoc; 
DOMElementx elementRoot'; 


// Obtener el elemento raíz del documento. 
xmlDoc = parser->getDocument(); 
elementRoot = xmlDoc->getDocumentElement(); 


XMLChx camera_ch = XMLString::transcode("camera"); 
XMLChx* graph_ch = XMLString: :transcode("graph"); 


// Procesando los nodos hijos del raíz... 
for (XMLSize_t i = 0; 
i < elementRoot->getChildNodes () ->getLength(); ++i ) f 
DOMNodex node = elementRoot->getChildNodes()->item(i) 


if (node->getNodeType() == DOMNode: : ELEMENT_NODE) € 

// Nodo <camera>? 

if (XMLString::equals(node->getNodeName(), camera_ch)) 
parseCamera(node, scene); 

else 


// Nodo <graph>? 
if (XMLString::equals(node->getNodeName(), graph_ch)) 
parseGraph(node, scene); 
y 
yY/ Fin for 
// Liberar recursos. 


) 





Estructurando código... Una buena programación estructurada es esencial para fa- 
O cilitar el mantenimiento del código y balancear de manera adecuada la complejidad 
de las distintas funciones que forman parte del mismo. 





Capítulo 
Bajo Nivel y Concurrencia 





David Vallejo Fernández 


rios para efectuar diversas tareas críticas para cualquier motor de juegos. Algunos 
ejemplos representativos de dichos subsistemas están vinculados al arranque y la 
parada del motor, su configuración y a la gestión de cuestiones de más bajo nivel. 


E ste capítulo realiza un recorrido por los sistemas de soporte de bajo nivel necesa- 


El objetivo principal del presente capítulo consiste en profundizar en dichas tareas y 
en proporcionar al lector una visión más detallada de los subsistemas básicos sobre los 
que se apoyan el resto de elementos del motor de juegos. 


En concreto, en este capítulo se discutirán los From the ground up! 


siguientes subsistemas: Los subsistemas de bajo nivel del mo- 


tor de juegos resultan esenciales pa- 


= Subsistema de arranque y parada. ra la adecuada integración de elemen- 
; 53d tos de más alto nivel. Algunos de ellos 

= Subsistema de gestión de contenedores. son simples, pero la funcionalidad que 
a A proporcionan es crítica para el correcto 

= Subsistema de gestión de cadenas. funcionamiento de otros subsistemas. 


El subsistema de gestión relativo a la gestión de contenedores de datos se discutió en 
el capítulo 5. En este capítulo se llevó a cabo un estudio de la biblioteca STL y se plan- 
tearon unos criterios básicos para la utilización de contenedores de datos en el ámbito del 
desarrollo de videojuegos con C++. Sin embargo, este capítulo dedica una breve sección a 
algunos aspectos relacionados con los contenedores que no se discutieron anteriormente. 


Por otra parte, el subsistema de gestión de memoria se estudiará en el módulo 3, titu- 
lado Técnicas Avanzadas de Desarrollo, del presente curso de desarrollo de videojuegos. 
Respecto a esta cuestión particular, se hará especial hincapié en las técnicas y las posibi- 
lidades que ofrece C++ en relación a la adecuada gestión de la memoria del sistema. 


Así mismo, en este capítulo se aborda la problemática relativa a la gestión de la 
concurrencia mediante un esquema basado en el uso de hilos y de mecanismos típicos 
de sincronización. 
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En los últimos años, el desarrollo de los procesadores, tanto de ordenadores persona- 
les, consolas de sobremesa e incluso teléfonos móviles, ha estado marcado por un modelo 
basado en la integración de varios núcleos físicos de ejecución. El objetivo principal de 
este diseño es la paralelización de las tareas a ejecutar por parte del procesador, permi- 
tiendo así incrementar el rendimiento global del sistema a través del paralelismo a nivel 
de ejecución. 


Este esquema, unido al concepto de hilo como unidad básica de ejecución de la CPU, 
ha permitido que aplicaciones tan exigentes como los videojuegos se pueden aprovechar 
de esta sustancial mejora de rendimiento. Desafortunadamente, no todo son buenas no- 
ticias. Este modelo de desarrollo basado en la ejecución concurrente de múltiples hilos 
de control tiene como consecuencia directa el incremento de la complejidad a la hora de 
desarrollar dichas aplicaciones. 


Además de plantear soluciones que sean paraleliza- 
bles y escalables respecto al número de unidades de pro- 
cesamiento, un aspecto crítico a considerar es el acceso 
concurrente a los datos. Por ejemplo, si dos hilos de eje- 
L1 Caché L1 Caché cución distintos comparten un fragmento de datos sobre 
el que leen y escriben indistintamente, entonces el progra- 
mador ha de integrar soluciones que garanticen la consis- 
tencia de los datos, es decir, soluciones que eviten situa- 
ciones en las que un hilo está escribiendo sobre dichos 
L2 Caché datos y otro está accediendo a los mismos. 


CPU Cpu 








Con el objetivo de abordar esta problemática des- 
de un punto de vista práctico en el ámbito del desa- 
rrollo de videojuegos, en este capítulo se plantean dis- 
tintos mecanismos de sincronización de hilos haciendo 
uso de los mecanismos nativos ofrecidos en C++11 
CPU CPU y, por otra parte, de la biblioteca de hilos de ZeroC 
ICE, un middleware de comunicaciones que proporcio- 
Figura 7.1: Esquema general de una Na una biblioteca de hilos que abstrae al desarrolla- 
CPU con varios procesadores. dor de la plataforma y el sistema operativo subyacen- 

tes. 





L1 Caché L1 Caché 











7.1. Subsistema de arranque y parada 


7.1.1. Aspectos fundamentales 


First things first! El subsistema de arranque y parada es el res- 
Elaranues la paradade UPaisiEnas ponsable de llevar a cabo la inicialización y confi- 
representa una tarea básica y, al mismo guración de los distintos subsistemas que forman 
tiempo, esencial para la correcta ges- parte del motor de juegos, así como de realizar la 


tión de los distintos componentes de la parada de los mismos cuando así sea necesario. Es- 

arquitectura de tin motor de juegos. te sistema forma parte de la capa de subsistemas 

principales que se introdujo brevemente en la sec- 

ción 1.2.4. La figura 7.2 muestra la interacción del subsistema de arranque y parada con 
el resto de componentes de la arquitectura general del motor de juegos. 


Este subsistema juega un papel básico pero fundamental dentro de la arquitectura del 
motor de juegos, ya que disponer de una entidad software que conozca las interdepen- 
dencias entre el resto de subsistemas es crucial para efectuar su arranque, configuración y 
parada de una manera adecuada. 
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Figura 7.2: Interacción del subsistema de arranque y parada con el resto de subsistemas de la arquitectura 


general del motor de juegos [5]. 


Desde un punto de vista general, si un subsistema S 
tiene una dependencia con respecto a un subsistema T”, 
entonces el subsistema de arranque ha de tener en cuen- 
ta dicha dependencia para arrancar primero T' y, a conti- 
nuación, S. Así mismo, la parada de dichos subsistemas 
se suele realizar generalmente en orden inverso, es decir, 
primero se pararía S y, posteriormente, T' (ver figura 7.3). 


En el ámbito del desarrollo de videojuegos, el subsis- 
tema de arranque y parada se suele implementar haciendo 
uso del patrón singleton, discutido en la sección 4.3.1, con 
el objetivo de manejar una única instancia de dicho sub- 
sistema que represente el único punto de gestión y evi- 
tando la reserva dinámica de memoria. Este planteamien- 
to se extiende a otros subsistemas relevantes que forman 
parte del motor de juegos. Comúnmente, este tipo de sub- 
sistemas también se suelen denominar gestores o mana- 
gers. La implementación típica de este tipo de elementos 
se muestra en el siguiente listado de código. 


Debido a que C++ es el lenguaje estándar pa- 
ra el desarrollo de videojuegos modernos, una posi- 
ble alternativa para gestionar de manera correcta tan- 
to el arranque como la parada de subsistemas po- 
dría consistir en hacer uso de los mecanismos nati- 
vos de C++ de construcción y destrucción de elemen- 
tos. 


Sub 
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Figura 7.3: Esquema gráfico de or- 
den de arranque y de parada de tres 
subsistemas dependientes entre sí. 
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Listado 7.1: Esqueleto básico del subsistema de gestión de memoria. 





1 class MemoryManager 4 
public: 
MemoryManager () 4 
// Inicialización gestor de memoria... 


2 

3 

4 
57) 
6 —MemoryManager () 4 

7 // Parada gestor de memoria... 
8 7) 

9 

10 A 

11. y; 


13 // Instancia única. 
14 static MemoryManager gMemoryManager; 





Variables globales. Recuerde que idealmente las variables globales se deberían li- 
mitar en la medida de lo posible con el objetivo de evitar efectos colaterales. 











Desde un punto de vista general, los objetos globales y estáticos se instancian de 
manera previa a la ejecución de la función main. Del mismo modo, dichos objetos se 
destruyen de manera posterior a la ejecución de dicha función, es decir, inmediatamente 
después de su retorno. Sin embargo, tanto la construcción como la destrucción de dichos 
objetos se realizan en un orden impredecible. 


La consecuencia directa del enfoque nativo proporcionado por C++ para la construc- 
ción y destrucción de objetos es que no se puede utilizar como solución directa para 
arrancar y parar los subsistema del motor de juegos. La razón se debe a que no es posible 
establecer un orden que considere las posibles interdependencias entre subsistemas. 


Listado 7.2: Subsistema de gestión de memoria con acceso a instancia única. 





1 class MemoryManager 4 

2 public: 

3 static MemoryManagerú get () 4 

4 static MemoryManager gMemoryManager; 

5 return gMemoryManager; 

6 7) 

7 MemoryManager () 4 

8 // Arranque de otros subsistemas dependientes... 
9 SubsistemaX: :get(); 

10 SubsistemaY: :get(); 

11 

12 // Inicialización gestor de memoria... 
13 J 

14 —MemoryManager () 4 

15 // Parada gestor de memoria... 

16 J 

17 1 NS 
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Una solución directa a esta problemática consiste en declarar la variable estática den- 
tro de una función, con el objetivo de obtenerla cuando así sea necesario. De este modo, 
dicha instancia no se instanciará antes de la función main, sino que lo hará cuando se efec- 
túe la primera llamada a la función implementada. El anterior listado de código muestra 
una posible implementación de esta solución. 





Variables no locales. La inicialización de variables estáticas no locales se controla 
A mediante el mecanismo que utilice la implementación para arrancar un programa en 
(Cho 











Una posible variante de este diseño consiste en reservar memoria de manera dinámica 
para la instancia única del gestor en cuestión, tal y como se muestra en el siguiente listado 
de código. 


static MemoryManageré get () 4 
static MemoryManager *gMemoryManager = NULL; 


if (gMemoryManager == NULL) 
gMemoryManager = new MemoryManager(); 


assert(gMemoryManager); 
return *gMemoryManager; 


7 


No obstante, aunque existe cierto control sobre el 
arranque de los subsistemas dependientes de uno en con- 
creto, esta alternativa no proporciona control sobre la pa- 
rada de los mismos. Así, es posible que C++ destruya uno MemoryManager 
de los subsistemas dependientes del gestor de memoria de 
manera previa a la destrucción de dicho subsistema. 





Además, este enfoque presenta el inconveniente aso- (0) get () 
ciado al momento de la construcción de la instancia glo- 
bal del subsistema de memoria. Evidentemente, la cons- 
trucción se efectuará a partir de la primera llamada a la Función main () 
función get, pero es complicado controlar cuándo se efec- 
tuará dicha llamada. 


Por otra parte, no es correcto realizar suposicio- 
nes sobre la complejidad vinculada a la obtención del 
singleton, ya que los distintos subsistemas tendrán ne- 
cesidades muy distintas entre sí a la hora de ini- Función main () 
cializar su estado, considerando las interdependencias 
con otros subsistemas. En general, este diseño puede 
ser problemático y es necesario proporcionar un es- Figura 7.4: Esquema gráfico de ob- 
quema sobre el que se pueda ejercer un mayor con-  'ención de un singleton y su posterior 


F z utilización. 
trol y que simplique los procesos de arranque y para- 
da. 
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7.1.2. Esquema típico de arranque y parada 


En esta subsección se estudia un enfoque simple [5], aunque ampliamente utilizado, 
para gestionar tanto el arranque como la parada de los distintos subsistemas que forman 
la arquitectura de un motor de juegos. La idea principal de este enfoque reside en expli- 
citar el arranque y la parada de dichos subsistemas, que a su vez se gestionan mediante 
managers implementados de acuerdo al patrón singleton. 


Para ello, tanto el arranque como la parada de un subsistema se implementa me- 
diante funciones explícitas de arranque y parada, típicamente denominadas startUp y 
shutDown, respectivamente. En esencia, estas funciones representan al constructor y al 
destructor de la clase. Sin embargo, la posibilidad de realizar llamadas permite controlar 
de manera adecuada la inicialización y parada de un subsistema. El orden del arranque, 
inicialización y parada de subsistemas dependerán de las relaciones entre los mismos. 
Por ejemplo, el subsistema de gestión de memoria será típicamente uno de los primeros 
en arrancarse, debido a que gran parte del resto de subsistemas tienen una dependencia 
directa respecto al primero. 


El siguiente listado de código muestra la implementación típica de un subsistema de 
gestión haciendo uso del enfoque planteado en esta subsección. Observe cómo tanto el 
constructor y el destructor de clase están vacíos, ya que se delega la inicialización del 
subsistema en las funciones startUp() y shutDown(). 


class MemoryManager f 
public: 
MemoryManager () (7 
-—MemoryManager () (7 


void startUp () £ 
// Inicialización gestor de memoria... 
, 
void shutDown () £ 
// Parada gestor de memoria... 
, 
$»; 


class RenderManager 4 /* IDEM */ ); 
class TextureManager £ /* IDEM x*/ P; 
class AnimationManager € /* IDEM */ ); 
DE 


MemoryManager gMemoryManager; 
RenderManager gRenderManager; 
TextureManager gTextureManager; 
AnimationManager gAnimationManager; 
LL 





Recuerde que la simplicidad suele ser deseable en la mayoría de los casos, aunque 
el rendimiento o el propio diseño de un programa se vean degradados. Este enfoque 

uw facilita el mantenimiento del código. El subsistema de arranque y parada es un caso 
típico en el ámbito de desarrollo de videojuegos. 











7.1. Subsistema de arranque y parada [235] 





Mediante este enfoque, la inicialización y parada de subsistemas es trivial y permite un 
mayor control sobre dichas tareas. En el siguiente listado de código se muestran de manera 
explícita las dependencias entre algunos de los subsistemas típicos de la arquitectura de 
motor, como por ejemplo los subsistemas de gestión de memoria, manejo de texturas, 
renderizado o animación. 


int main () € 
// Arranque de subsistemas en orden. 
gMemoryManager.startUp(); 
gTextureManager.startUp(); 
gRenderManager.startUp(); 
gAnimationManager.startUp(); 
LE sa 


// Bucle principal. 
gSimulationManager.run(); 


// Parada de subsistemas en orden. 
LE 
gAnimationManager.startUp(); 
gRenderManager.startUp(); 
gTextureManager.startup(); 
gMemoryManager.startUp(); 


return 0; 


7.1.3. Caso de estudio. Ogre 3D 


Aunque Ogre 3D es en realidad un motor de renderizado en lugar de un completo 
motor de juegos, dicho entorno proporciona una gran cantidad de subsistemas relevantes 
para facilitar el desarrollo de videojuegos. Entre ellos, también existe un subsistema de 
arranque y parada que hace gala de una gran simplicidad y sencillez. 


Básicamente, el arranque y la parada en Ogre se realiza a través del uso de la clase 
Ogre::Root, la cual implementa el patrón singleton con el objetivo de asegurar una única 
instancia de dicha clase, la cual actúa como punto central de gestión. 


Para ello, la clase Root almacena punteros, co- 


z ñ ñ A Ogre::Singleton 
mo variables miembro privadas, a todos los subsis- 


La clase Ogre::Singleton está basada 


temas soportados por Ogre con el objetivo de ges- en el uso de plantillas para poder ins- 
tionar su creación y su destrucción. El siguiente lis- tanciarla para tipos particulares. Dicha 
tado de código muestra algunos aspectos relevantes clase proporciona las típicas funciones 
de la declaración de esta clase. getSingleton() y gerSingletonPer para 


acceder a la referencia y al puntero, 
Como se puede apreciar, la clase Root hereda respectivamente, de la única instancia 


de la clase Ogre::Singleton, que a su vez hace uso  Jeclase creada, 

de plantillas y que, en este caso, se utiliza para es- 

pecificar el singleton asociado a la clase Roof. Así mismo, dicha clase hereda de RoofA- 
lloc, que se utiliza como superclase para todos los objetos que deseen utilizar un asignador 
de memoria personalizado. 
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Ogre::Singleton<Root> RootAlloc 


Ogre::Root 


Figura 7.5: Clase Ogre::Root y su relación con las clases Ogre::Singleton y RootAlloc. 


Listado 7.6: Clase Ogre::Root. 


1 class _OgreExport Root : public Singleton<Root>, public RootAlloc 
24 

3 protected: 

4 // Más declaraciones... 

5 // Gestores (implementan el patrón Singleton). 

6 LogManagerx* mLogManager; 

7 ControllerManagerx* mControllerManager; 

8 SceneManagerEnumeratorx* mSceneManagerEnum; 

9 DynLibManagerx* mDynLibManager; 

10 ArchiveManagerx* mArchiveManager; 

11 MaterialManager* mMaterialManager; 

12 MeshManagerx* mMeshManager; 

13 ParticleSystemManager* mParticleManager; 

14 SkeletonManagerx* mSkeletonManager; 

15 OverlayElementFactoryx mPanelFactory; 

16 OverlayElementFactory* mBorderPanelFactory; 

17 OverlayElementFactoryx mTextAreaFactory; 

18 OverlayManager* mOverlayManager; 

19 FontManagerx* mFontManager; 

20 ArchiveFactory *mZipArchiveFactory; 

21 ArchiveFactory *mFileSystemArchiveFactory; 

22 ResourceGroupManagerx mResourceGroupManager; 

23 ResourceBackgroundQueuex* mResourceBackgroundQueue; 
24 ShadowTextureManager* mShadowTextureManager; 

25 RenderSystemCapabilitiesManager* mRenderSystemCapabilitiesManager; 
26 ScriptCompilerManager *mCompilerManager; 

27 // Más declaraciones... 

28 y; 


El objeto Root representa el punto de entrada de Ogre y ha de ser el primer objeto 
instanciado en una aplicación y el último en ser destruido. Típicamente, la clase principal 
de los ejemplos básicos desarrollados tendrán como variable miembro una instancia de la 
clase Root, con el objetivo de facilitar la administración del juego en cuestión. 
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Desde el punto de vista del renderizado, el objeto de tipo Root proporciona la función 
startRendering. Cuando se realiza una llamada a dicha función, la aplicación entrará en 
un bucle de renderizado continuo que finalizará cuando todas las ventanas gráficas se 
hayan cerrado o cuando todos los objetos del tipo FrameListener finalicen su ejecución 
(ver módulo 2, Programación Gráfica). 


La implementación del constructor de la clase Ogre::Root tiene como objetivo prin- 
cipal instanciar y arrancar los distintos subsistemas previamente declarados en el anterior 
listado de código. A continuación se muestran algunos aspectos relevantes de la imple- 
mentación de dicho constructor. 


Listado 7.7: Clase Ogre::Root. Constructor. 





1 Root::Root(const Strings pluginFileName, const Strings configFileName, 
2 const Strings logFileName) 

3 // Inicializaciones... 

4 1 

5 // Comprobación del singleton en clase padre. 

6 // Inicialización. 

7 LISPE: ce 

8 

9 


// Creación del log manager y archivo de log por defecto. 
10 if(LogManager::getSingletonPtr() == 0) 4 


11 mLogManager = OGRE_NEW LogManager()'; 

12 mLogManager->createLog(logFileName, true, true); 
13 J 

14 


15 // Gestor de biblioteca dinámica. 
16 mDynLibManager = OGRE_NEW DynLibManager(); 
17 mArchiveManager = OGRE_NEW ArchiveManager(); 


19 // ResourceGroupManager. 
20 mResourceGroupManager = OGRE_NEW ResourceGroupManager(); 


22 LE ISC 


24 // Material manager. 

25 mMaterialManager = OGRE_NEW MaterialManager(); 

26 // Mesh manager. 

27 mMeshManager = OGRE_NEW MeshManager(); 

28 // Skeleton manager. 

29 mSkeletonManager = OGRE_NEW SkeletonManager(); 

30 // Particle system manager. 

31 mParticleManager = OGRE_NEW ParticleSystemManager(); 
32 II SPCEu 





Start your engine! Aunque el arranque y la parada de los motores de juegos actua- 

A les suelen estar centralizados mediante la gestión de algún elemento central, como 
por ejemplo la clase Ogre::Root, es responsabilidad del desarrollador conocer los 
elementos accesibles desde dicha entidad de control central. 
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7.1.4. Caso de estudio. Quake II 


tr 


Figura 7.6: Quake III Arena es un 
juego multijugador en primera per- 
sona desarrollado por IdSoftware y 
lanzado el 2 de Diciembre de 1999. 
El modo de juego online fue uno de 
los más populares en su época. 


El código fuente de Quake III! fue liberado bajo licen- 
cia GPLv2 el día 20 de Agosto de 2005. La fecha de libe- 
ración del código de Quake III no es casual. En realidad, 
coincide con el cumpleaños de John Carmack, una de las 
figuras más reconocidas dentro del ámbito del desarrollo 
de videojuegos, nacido el 20 de Agosto de 1970. 


Desde su liberación, la comunidad amateur de desa- 
rrollo ha realizado modificaciones y mejoras e incluso el 
propio motor se ha reutilizado para el desarrollo de otros 
juegos. El diseño de los motores de Quake es un muy 
buen ejemplo de arquitectura bien estructurada y modu- 
larizada, hecho que posibilita el estudio de su código y la 
adquisición de experiencia por el desarrollador de video- 
juegos. 


En esta sección se estudiará desde un punto de vis- 
ta general el sistema de arranque y de parada de Quake 
IT. Al igual que ocurre en el caso de Ogre, el esquema 


planteado consiste en hacer uso de funciones específicas para el arranque, inicialización 
y parada de las distintas entidades o subsistemas involucrados. 


El siguiente listado de código muestra el punto de entrada de Quake III para sis- 
temas Windows'"M. Como se puede apreciar, la función principal consiste en una serie 
de casos que determinan el flujo de control del juego. Es importante destacar los casos 
GAME_INIT y GAME_SHUTDOWN que, como su nombre indica, están vinculados al 
arranque y la parada del juego mediante las funciones G_InitGame() y G_ShutdownGa- 


me(), respectivamente. 


IPPO OA EOS 


int vmMain( int command, int arg0, int argl, ..., int argl1 ) ( 


switch ( command ) X 


// Se omiten algunos casos. 


G_InitGame( arg0, argl, arg2 ); 


return 0; 
case GAME_SHUTDOWN: 
G_ShutdownGame( arg0 ); 
9 return 0; 
10 case GAME_CLIENT_CONNECT: 


1 
2 
3 
4 case GAME_INIT: 
5 
6 
7 
8 


11 


return (int)ClientConnect( arg0, argl, arg2 ); 


12 case GAME_CLIENT_DISCONNECT: 
13 ClientDisconnect( arg0 ); 
14 return 0; 

15 case GAME_CLIENT_BEGIN: 

16 ClientBegin( arg0 ); 

17 return 0; 

18 case GAME_RUN_FRAME: 

19 G_RunFrame( arg0 ); 

20 return 0; 

21 case BOTAI_START_FRAME: 

22 return BotAlStartFrame( arg0 ); 
23 , 

24 

25 return -1; 

26 ) 





Ihttps://github.com/id-Software/Quake-1III-Arena 
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Recuerde que Quake III está desarrollado utilizando el lenguaje C. El código fuente 
está bien diseñado y estructurado. Para tener una visión global de su estructura se 

u recomienda visualizar el archivo g_local.h, en el que se explicita el fichero de las 
funciones más relevantes del código. 











A continuación se muestran los aspectos más destacados de la función de iniciali- 
zación de Quake III. Como se puede apreciar, la función G_/nitGame() se encarga de 
inicializar los aspectos más relevantes a la hora de arrancar el juego. Por ejemplo, se 
inicializan punteros relevantes para manejar elementos del juego en G_/nitMemory(), se 
resetean valores si la sesión de juego ha cambiado en G_/nitWorldSession(), se inicializan 
las entidades del juego, etcétera. 


Listado 7.9: Quake 3. Función G_InitGame. 


void G_InitGame( int levelTime, int randomSeed, int restart ) 
// Se omite parte del código fuente... 


G_InitMemory(); 
Vb citas 


1 
2 
3 
4 
5 
6 
7 
8 G_InitWorldSession(); 

9 

10 // Inicialización de entidades del juego. 

11 memset( g_entities, 0, MAX_GENTITIES x sizeof(g_entities[0]) ); 
12 level .gentities = g_entities; 

13 

14 // Inicialización de los clientes. 

15 level.maxclients = g_maxclients.integer; 

16 memset( g_clients, 0, MAX_CLIENTS x sizeof(g_clients[0]) ); 

17 level.clients = g_clients; 

18 

19 // Establecimiento de campos cuando entra un cliente. 

20 for ( i=0 ; i<level.maxclients ; i++ ) X 

21 g-entities[il.client = level.clients + i; 

22 , 

23 

24 // Reservar puntos para jugadores eliminados. 

25 InitBodyQue(); 

26 // Inicialización general. 

27 G_FindTeams(); 

28 

29 dl 

30 y 


La filosofía seguida para parar de manera adecuada el juego es análoga al arranca e 
inicialización, es decir, se basa en centralizar dicha funcionalidad en sendas funciones. 
En este caso concreto, la función G_ShutdownGame() es la responsable de llevar a cabo 
dicha parada. 
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Figura 7.7: Visión abstracta del flujo general de ejecución de Quake III Arena (no se considera la conexión y 
desconexión de clientes). 


Listado 7.10: Quake 3. Función G_ShutdownGame. 


1 void G_ShutdownGame( int restart ) (f 

2 G_Printf ("==== ShutdownGame ====1n"); 
3 if ( level.logFile ) £ 

4 G_LogPrintf("ShutdownGame:Yn" ); 

5 

6 

7 

8 










vwMain () G_InitGame () 























trap_FS_FCloseFile( level.logFile ); 
) 


// Escritura de los datos de sesión de los clientes, 
9 // para su posterior recuperación. 
10 G_WriteSessionData(); 


11 

12 if ( trap_Cvar_VariablelntegerValue( "bot_enable" ) ) 4 
13 BotAIShutdown( restart ); 

14 , 

15 ) 


Como se puede apreciar en la función de parada, básicamente se escribe información 
en el fichero de log y se almacenan los datos de las sesiones de los clientes para, pos- 
teriormente, permitir su recuperación. Note cómo en las líneas se delega la parada 
de los bots, es decir, de los NPCs en la función BotAIShutdown(). De nuevo, el esquema 
planteado se basa en delegar la parada en distintas funciones en función de la entidad 
afectada. 


A su vez, la función BotAIShutdown() delega en otra función que es la encargada, 
finalmente, de liberar la memoria y los recursos previamente reservados para el caso par- 
ticular de los jugadores que participan en el juego, utilizando para ello la función BotAIS- 
hutdownClient(). 


Listado 7.11: Quake 3. Funciones BotAIShutdown y BotAIShutdownClient. 


1 int BotAlShutdown( int restart ) £ 

2 if ( restart ) X // Si el juego se resetea para torneo... 

3 for (i = 0; i < MAX_CLIENTS; i++) // Parar todos los bots en botlib. 
4 if (botstates[i] 66 botstates[i]->inuse) 

5 BotAIShutdownClient(botstates[i]->client, restart); 

6 7) 

Tod 

8 

9 


int BotAlShutdownClient(int client, qboolean restart) 
10 // Se omite parte del código. 
11 // Liberar armas... 
12 trap_BotFreeWeaponState(bs->wS); 
13 // Liberar el bot... 
14 trap_BotFreeCharacter(bs->character); 
15 LE kx 
16 // Liberar el estado del bot... 
17 memset(bs, 0, sizeof(bot_state_t)); 
18 // Un bot menos... 
19 numbots--; 
20 1d O 
21 // Todo OK. 
22 return qtrue; 
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Programación estructurada. El código de Ouake es un buen ejemplo de programa- 
uy ción estructurada que gira en torno a una adecuada definición de funciones y a un 
equilibrio respecto a la complejidad de las mismas. 











7.2. Contenedores 


Como ya se introdujo en el capítulo 5, los contenedores son simplemente objetos que 
contienen otros objetos. En el mundo del desarrollo de videojuegos, y en el de las aplica- 
ciones software en general, los contenedores se utilizan extensivamente para almacenar 
las estructuras de datos que conforman la base del diseño que soluciona un determinado 
problema. 


Algunos de los contenedores más conocidos ya se comentaron en las secciones 5.3, 5.4 
y 5.5. En dichas secciones se hizo un especial hincapié en relación a la utilización de estos 
contenedores, atendiendo a sus principales caracteristicas, como la definición subyacente 
en la biblioteca STL. 


En esta sección se introducirán algunos aspectos fundamentales que no se discutieron 
anteriormente y se mencionarán algunas bibliotecas útiles para el uso de algunas estruc- 
turas de datos que son esenciales en el desarrollo de videojuegos, como por ejemplo los 
grafos. Estos aspectos se estudiarán con mayor profundidad en el módulo 3, Técnicas 
Avanzadas de Desarrollo. 


7.2.1. Iteradores 


Desde un punto de vista abstracto, un iterador se puede definir como una clase que per- 
mite acceder de manera eficiente a los elementos de un contenedor específico. Según [17], 
un iterador es una abstracción pura, es decir, cualquier elemento que se comporte como 
un iterador se define como un iterador. En otras palabras, un iterador es una abstracción 
del concepto de puntero a un elemento de una secuencia. Normalmente, los iteradores se 
implementan haciendo uso del patrón que lleva su mismo nombre, tal y como se discutió 
en la sección 4.5.3. Los principales elementos clave de un iterador son los siguientes: 


= El elemento al que apunta (desreferenciado mediante los operadores * y ->). 


= La posibilidad de apuntar al siguiente elemento (incrementándolo mediante el ope- 
rador ++). 


= La igualdad (representada por el operador ==). 


De este modo, un elemento primitivo int* se puede definir como un iterador sobre un 
array de enteros, es decir, sobre int[]. Así mismo, std::list<std::string>::iterator es un 
iterador sobre la clase list. 


Un iterador representa la abstracción de un puntero dentro de un array, de manera que 
no existe el concepto de iterador nulo. Como ya se introdujo anteriormente, la condición 
para determinar si un iterador apunta o no a un determinado elemento se evalúa mediante 
una comparación al elemento final de una secuencia (end). 





Rasgos de iterador. En STL, los tipos relacionados con un iterador se describen 
a partir de una serie de declaraciones en la plantilla de clase iterator_traits. Por 

li) ejemplo, es posible acceder al tipo de elemento manejado o el tipo de las operaciones 
soportadas. 
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Acceso 
directo 


Bidireccional Unidireccional Entrada 





Salida 


Figura 7.8: Esquema gráfica de las relaciones entre las distintas categorías de iteradores en STL. Cada categoría 
implementa la funcionalidad de todas las categorías que se encuentran a su derecha. 


Categorías de iteradores y operaciones 























Categoría Salida Entrada Unidireccional Bidireccional Acceso directo 
Lectura ="p =*p =*p =*p 
Acceso > > > ->[] 
Escritura *p= *p= *p= *p= 
Iteración ++ ++ ++ ++- +++ += = 
Comparación == |= == |= == |= == l= <><= >= 





Tabla 7.1: Resumen de las principales categorías de iteradores en STL junto con sus operaciones [17]. 


Las principales ventajas de utilizar un iterador respecto a intentar el acceso sobre un 
elemento de un contenedor son las siguientes [5]: 


= El acceso directo rompe la encapsulación de la clase contenedora. Por el contrario, 
el iterador suele ser amigo de dicha clase y puede iterar de manera eficiente sin 
exponer detalles de implementación. De hecho, la mayoría de los contenedores 
ocultan los detalles internos de implementación y no se puede iterar sobre ellos sin 
un iterador. 


= El iterador simplifica el proceso de iteración. La mayoría de iteradores actúan co- 
mo índices o punteros, permitiendo el uso de estructuras de bucle para recorrer un 
contenedor mediante operadores de incremento y comparación. 


Dentro de la biblioteca STL existen distintos tipos de contenedores y no todos ellos 
mantienen el mismo juego de operaciones. Los iteradores se clasifican en cinco categorías 
diferentes dependiendo de las operaciones que proporcionan de manera eficiente, es decir, 


en tiempo constante (O(1)). La tabla 7.1 resume las distintas categorías de iteradores junto 


con sus operaciones? . 


Recuerde que tanto la lectura como la escritura se realizan mediante el iterador desre- 
ferenciado por el operador *. Además, de manera independiente a su categoría, un iterador 
puede soportar acceso const respecto al objeto al que apunta. No es posible escribir sobre 
un determinado elemento utilizando para ello un operador const, sea cual sea la categoría 
del iterador. 





No olvide implementar el constructor de copia y definir el operador de asignación 
Le para el tipo que se utilizará en un contenedor y que será manipulado mediante itera- 
dores, ya que las lecturas y escrituras copian objetos. 














2http ://www.cplusplus.com/reference/std/iterator/ 
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Los iteradores también se pueden aplicar sobre flujos de E/S gracias a que la biblioteca 
estándar proporciona cuatro tipos de iteradores enmarcados en el esquema general de 
contenedores y algoritmos: 


= ostream_iterator, para escribir en un ostream. 
= istream_iterator, para leer de un istream. 
= ostreambuf_iterator, para escribir en un buffer de flujo. 


= istreambuf_iterator, para leer de un buffer de flujo. 


El siguiente listado de código muestra un ejemplo en el que se utiliza un iterador para 
escribir sobre la salida estándar. Como se puede apreciar, el operador ++ sirve para des- 
plazar el iterador de manera que sea posible llevar a cabo dos asignaciones consecutivas 
sobre el propio flujo. De no ser así, el código no sería portable. 


Htinclude <iostream> 
Htinclude <iterator> 


using namespace std; 


int main () € 
// Escritura de enteros en cout. 
ostream_iterator<int> fs(cout); 


*fs = 7; // Escribe 7 (usa cout). 
+H!fs; // Preparado para siguiente salida. 
*fs = 6; // Escribe 6. 


return 0; 


7.2.2. Más allá de STL 


Como ya se discutió anteriormente en el capítulo 5, gran parte de los motores de juego 
tienen sus propias implementaciones de los contenedores más utilizados para el manejo 
de sus estructuras de datos. Este planteamiento está muy extendido en el ámbito de las 
consolas de sobremesa, las consolas portátiles, los teléfonos móviles y las PDA (Personal 
Digital Assistant)s. Los principales motivos son los siguientes: 


= Control total sobre los contenedores y estructuras de datos desarrolladas, especial- 
mente sobre el mecanismo de asignación de memoria, aunque sin olvidar aspectos 
como los propios algoritmos. Aunque STL permite crear asignadores de memoria 
personalizados (custom allocators), en ocasiones los propios patrones de los conte- 
nedores de STL pueden ser insuficientes. 


= Optimizaciones, considerando el propio hardware sobre el que se ejecutará el mo- 
tor. STL es un estándar independiente de la plataforma y el sistema operativo, por 
lo que no es posible aplicar optimizaciones de manera directa sobre la propia bi- 
blioteca. 
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= Personalización debido a la necesidad de incluir funcionalidad sobre un contene- 
dor que no esté inicialmente considerada en otras bibliotecas como STL. Por ejem- 
plo, en un determinado problema puede ser necesario obtener los n elementos más 
adecuados para satisfacer una necesidad. 


= Independencia funcional, ya que es posible depurar y arreglar cualquier problema 
sin necesidad de esperar a que sea solucionado por terceras partes. 


De manera independiente al hecho de considerar la opción de usar STL, existen otras 
bibliotecas relacionadas que pueden resultar útiles para el desarrollador de videojuegos. 
Una de ellas es STLPort, una implementación de STL específicamente ideada para ser 
portable a un amplio rango de compiladores y plataformas. Esta implementación propor- 
ciona una funcionalidad más rica que la que se puede encontrar en otras implementaciones 
de STL. 





Uso comercial de STL. Aunque STL se ha utilizado en el desarrollo de videojuegos 
comerciales, actualmente es más común que el motor de juegos haga uso de una 

Wy biblioteca propia para la gestión de contenedores básicos. Sin embargo, es bastante 
común encontrar esquemas que siguen la filosofía de STL, aunque optimizados en 
aspectos críticos como por ejemplo la gestión y asignación de memoria. 











La otra opción que se discutirá brevemente en esta sección es el proyecto Boost, cuyo 
principal objetivo es extender la funcionalidad de STL. Gran parte de las bibliotecas del 
proyecto Boost están en proceso de estandarización con el objetivo de incluirse en el pro- 
pio estándar de C++. Las principales características de Boost se resumen a continuación: 


= Inclusión de funcionalidad no disponible en STL. 


= En ocasiones, Boost proporciona algunas alternativas de diseño e implementación 
respecto a STL. 


= Gestión de aspectos complejos, como por ejemplos los smart pointers. 


= Documentación de gran calidad que también incluye discusiones sobre las decisio- 
nes de diseño tomadas. 


Para llevar a cabo la instalación de STLPortf? y Boost* (incluída la biblioteca para 
manejo de grafos) en sistemas operativos Debian y derivados es necesarios ejecutar los 
siguientes comandos: 


$ sudo apt-get update 
$ sudo apt-get install libstlport5.2-dev 
$ sudo apt-get install libboost-dev 
$ sudo apt-get install libboost-graph-dev 


La figura 7.9 muestra un grafo dirigido que servirá como base para la discusión del 
siguiente fragmento de código, en el cual se hace uso de la biblioteca Boost para llevar a 
cabo el cálculo de los caminos mínimos desde un vértice al resto mediante el algoritmo 
de Dijkstra. 





Las bibliotecas de Boost se distribuyen bajo la Boost Software Licence, la cual per- 
mite el uso comercial y no-comercial. 














http://www. stlport.org 
4http://www.boost.org 
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Figura 7.9: Representación gráfica del grafo de ejemplo utilizado para el cálculo de caminos mínimos. La parte 
derecha muestra la implementación mediante listas de adyacencia planteada en la biblioteca Boost. 


Recuerde que un grafo es un conjunto no vacío de nodos o vértices y un conjunto 
de pares de vértices o aristas que unen dichos nodos. Un grafo puede ser dirigido o no 
dirigido, en función de si las aristas son unidireccionales o bidireccionales, y es posible 
asignar pesos a las aristas, conformando así un grafo valorado. 





Edsger W. Dijkstra. Una de las personas más relevantes en el ámbito de la compu- 
tación es Dijkstra. Entre sus aportaciones, destacan la solución al camino más corto, 

(1) la notación polaca inversa, el algoritmo del banquero, la definición de semáforo como 
mecanismo de sincronización e incluso aspectos de computación distribuida, entre 
otras muchas contribuciones. 











A continuación se muestra un listado de código (adaptado a partir de uno de los ejem- 
plos de la biblioteca?) que permite la definición básica de un grafo dirigido y valorado. 
El código también incluye cómo hacer uso de funciones relevantes asociadas los grafos, 
como el cálculo de los cáminos mínimos de un determinado nodo al resto. 


Como se puede apreciar en el siguiente código, es posible diferenciar cuatro bloques 
básicos. Los tres primeros se suelen repetir a la hora de manejar estructuras mediante la 
biblioteca Boost Graph. En primer lugar, se lleva a cabo la definición de los tipos de datos 
que se utilizarán, destacando el propio grafo (líneas (14-15) y los descriptores para manejar 
tanto los vértices (línea (15) y las aristas (líneas (17-18)). A continuación se especifican los 
elementos concretos del grafo, es decir, las etiquetas textuales asociadas a los vértices, 
las aristas o arcos y los pesos de las mismas. Finalmente, ya es posible instanciar el grafo 
(línea (32), el descriptor usado para especificar el cálculo de caminos mínimos desde A 
(línea (38) y la llamada a la función para obtener dichos caminos ((41-42)). 





Shttp ://www.boost.org/doc/libs/1_55_0/libs/graph/example/dijkstra-example.cpp 
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Listado 7.13: Ejemplo de uso de la biblioteca Boost (grafos). 


1 *tinclude <boost/config.hpp> 
2 Htinclude <iostream> 


3 


4 Htinclude <boost/graph/graph_traits.hpp> 
5 *tinclude <boost/graph/adjacency_list.hpp> 
6 *tinclude <boost/graph/dijkstra_shortest_paths.hpp> 


7 
8 using namespace boost; 
9 
10 int 
11 main(int, char x*[]) 
12 4 
13 // Definición de estructuras de datos... 
14 typedef adjacency_list <listS, vecS, directedS, 
15 no_property, property <edge_weight_t, int> > graph_t; 
16 typedef graph_traits <graph_t>::vertex_descriptor vertex_descriptor; 
17 typedef graph_traits <graph_t>: :edge_descriptor edge_descriptor; 
18 typedef std::pair<int, int> Edge; 
19 
20 // Parámetros básicos del grafo. 
21 const int num_nodes = 5; 
22 enum nodes (A, B, C, D, E); 
23 char name[] = "ABCDE"; 
24 Edge edge_array[] = 4 
25 Edge(A, C), Edge(B, A), Edge(B, D), Edge(C, D), Edge(D, B) 
26 Edge(D, C), Edge(D, E), Edge(E, A), Edge(E, B), Edge(E, C) 
27 Y; 
28 int weights[] = (2, 7, 4, 2, 12, 4, 3, 1, 2, 3); 
29 int num_arcs = sizeof(edge_array) / sizeof (Edge); 
30 
31 // Instanciación del grafo. 
32 graph_t g(edge_array, edge_array + num_arcs, weights, num_nodes); 
33 property_map<graph_t, edge_weight_t>::type weightmap = 
34 get(edge_weight, 9); 
35 
36 std: :vector<vertex_descriptor> p(num_vertices(g)); 
37 std: :vector<int> d(num_vertices(g)); 
38 vertex_descriptor s = vertex(A, g); // CAMINOS DESDE A. 
39 
40 // Algoritmo de Dijkstra. 
41 dijkstra_shortest_paths(g, Ss, 
42 predecessor_map(Sp[0]).distance_map(8$d[0])); 
43 
44 std::cout << "Distancias y nodos padre:" << std: :endl; 
45 graph_traits <graph_t>::vertex_iterator vi, vend; 
46 for (boost::tie(vi, vend) = vertices(g); vi != vend; ++vi) £ 
47 std::cout << "Distancia(" << name[*vi] << ") = " 
48 << d[*vi] << ", "; 
49 std::cout << "Padre(" << name[x*vi] << ") = " << name[p[*vi]] 
50 << std:: endl; 
51 , 
52 std::cout << std: :endl; 
53 
54 return EXIT_SUCCESS; 
55 y 


El último bloque de código (líneas (41-52) (44-52)) permite obtener la información relevante a 
partir del cálculo de los caminos mínimos desde A, es decir, la distancia que existe desde 
el propio nodo A hasta cualquier otro y el nodo a partir del cual se accede al destino final 
(partiendo de A). 


Para generar un ejecutable, simplemente es necesario enlazar con la biblioteca boost_ 


graph: 


$ g++ dijkstra.cpp -o dijkstra -lboost_graph 
$ ./dijkstra 


7.3. Subsistema de gestión de cadenas 
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Al ejecutar, la salida del programa mostrará todos los caminos mínimos desde el vér- 


tice especificado; en este caso, desde el vértice A. 


Distancias y nodos padre: 


Distancia(A) = 0, Padre(A) = A 
Distancia(B) = 9, Padre(B) = E 
Distancia(C) = 2, Padre(C) = A 
Distancia(D) = 4, Padre(D) = C 
Distancia(E) = 7, Padre(E) = D 


7.3. Subsistema de gestión de cadenas 


Al igual que ocurre con otros elementos transversa- 
les a la arquitectura de un motor de juegos, como por 
ejemplos los contenedores de datos (ver capítulo 5), las 
cadenas de texto se utilizan extensivamente en cualquier 
proyecto software vinculado al desarrollo de videojuegos. 


Aunque en un principio pueda parecer que la uti- 
lización y la gestión de cadenas de texto es una 
cuestión trivial, en realidad existe una gran varie- 
dad de técnicas y restricciones vinculadas a este ti- 
po de datos. Su consideración puede ser muy relevan- 
te a la hora de mejorar el rendimiento de la aplica- 
ción. 


7.3.1. Cuestiones específicas 


Uno de los aspectos críticos a la hora de tratar con ca- 
denas de texto está vinculado con el almacenamiento y 
gestión de las mismas. Si se considera el hecho de utilizar 
C/C++ para desarrollar un videojuego, entonces es impor- 
tante no olvidar que en estos lenguajes de programación 
las cadenas de texto no son un tipo de datos atómica, ya 
que se implementan mediante un array de caracteres. 


typedef basic_string<char> string; 


La consecuencia directa de esta implementación es 
que el desarrollador ha de considerar cómo gestionar la 
reserva de memoria para dar soporte al uso de cadenas: 


= De manera estática, es decir, reservando una canti- 
dad fija e inicial de memoria para el array de carac- 
teres. 


= De manera dinámica, es decir, asignando en 
tiempo de ejecución la cantidad de memo- 
ria que se necesite para cubrir una necesi- 
dad. 





Figura 7.10: Esquema gráfico de la 
implementación de una cadena me- 
diante un array de caracteres. 
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Típicamente, la opción más utilizada por los programadores de C++ consiste en hacer 
uso de una clase string. En particular, la clase string proporcionada por la biblioteca es- 
tándar de C++. Sin embargo, en el contexto del desarrollo de videojuegos es posible que 
el desarrollador haya decidido no hacer uso de STL, por lo que sería necesario llevar a 
cabo una implementación nativa. 


Internationalization Otro aspecto fundamental relativo a las cade- 
La lelzación enel Abilo de pestón nas es la localización, es decir, el proceso de adap- 
de múltiples lenguajes, se suele cono- tar el software desarrollado a múltiples lenguajes. 
cer como internationalization, o 118N, Básicamente, cualquier representación textual del 
y es esencial para garantizar la inexis- juego, normalmente en inglés en un principio, ha 


tencia de problemas al tratar con dife- 


de de traducirse a los idiomas soportados por el juego. 
rentes idiomas. 


Esta cuestión plantea una problemática variada, co- 
mo por ejemplo la necesidad de tener en cuenta diversos alfabetos con caracteres especí- 
ficos (por ejemplo chino o japonés), la posibilidad de que el texto tenga una orientación 
distinta a la occidental o aspectos más específicos, como por ejemplo que la traducción 
de un término tenga una longitud significativamente más larga, en términos de longitud 
de caracteres, que su forma original. 


Desde un punto de vista más interno al propio desarrollo, también hay que considerar 
que las cadenas se utilizan para identificar las distintas entidades del juego. Por ejem- 
plo, es bastante común adoptar un convenio para nombrar a los posibles enemigos del 
personaje principal en el juego. Un ejemplo podría ser flying-enemy-robot-02. 


Finalmente, el impacto de las operaciones típicas de cadenas es muy importante con 
el objetivo de obtener un buen rendimiento. Por ejemplo, la comparación de cadenas me- 
diante la función stremp() tiene una complejidad lineal respecto a la longitudad de las 
cadenas, es decir, una complejidad O(n). Del mismo modo, la copia de cadenas también 
tiene una complejidad lineal, sin considerar la posibilidad de reservar memoria de ma- 
nera dinámica. Por el contrario, la comparación de tipos de datos más simples, como los 
enteros, es muy eficiente y está soportado por instrucciones máquina. 





El tratamiento de cadenas en tiempo de ejecución es costoso. Por lo tanto, evaluar su 
YN impacto es esencial para obtener un buen rendimiento. 











7.3.2. Optimizando el tratamiento de cadenas 


El uso de una clase string que abstraiga de la complejidad subyacente de la imple- 
mentación de datos textuales es sin duda el mecanismo más práctico para trabajar con 
cadenas. Por ejemplo, en el caso de C++, el programador puede utilizar directamente 
la clase string? de la biblioteca estándar. Dicha clase proporciona una gran cantidad de 
funcionalidad, estructurada en cinco bloques bien diferenciados: 


= Tteradores, que permiten recorrer de manera eficiente el contenido de las instancias 
de la clase string. Un ejemplo es la función begin(), que devuelve un iterador al 
comienzo de la cadena. 


= Capacidad, que proporciona operaciones para obtener información sobre el tama- 
ño de la cadena, redimensionarla e incluso modificar la cantidad de memoria reser- 
vada para la misma. Un ejemplo es la función size(), que devuelve la longitudad de 
la cadena. 





Shttp ://www.cplusplus.com/reference/string/string/ 
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= Acceso, que permite obtener el valor de caracteres concretos dentro de la cadena. 
Un ejemplo es la función at(), que devuelve el carácter de la posición especificada 
como parámetro. 


= Modificadores, que proporcionan la funcionalidad necesaria para alterar el conte- 
nido de la cadena de texto. Un ejemplo es la función swap(), que intercambia el 
contenido de la cadena por otra especificada como parámetro. 


= Operadores de cadena, que define operaciones auxiliares para tratar con cadenas. 
Un ejemplo es la función compare(), que permite comparar cadenas. 


No obstante, tal y como se introdujo anteriormente, la abstracción proporcionada por 
este tipo de clases puede ocultar el coste computacional asociado a la misma y, en con- 
secuencia, condicionar el rendimiento del juego. Por ejemplo, pasar una cadena de texto 
como parámetro a una función utilizando el estilo C, es decir, pasando un puntero al pri- 
mer elemento de la cadena, es una operación muy eficiente. Sin embargo, pasar un objeto 
cadena puede ser ineficiente debido a la generación de copias mediante los constructores 
de copia, posiblemente provocando reserva dinámica de memoria y penalizando aún más 
el rendimiento de la aplicación. 


Por este tipo de motivos, es bastante común que Profiling strings! 


en el desarrollo profesional de videojuegos se evite luso de hemamicn Doa ps 


el uso de clases string [5], especialmente en plata- ra evaluar el impacto del uso y gestión 
formas de propósito específico como las consolas de una implementación concreta de ca- 
de sobremesa. Si, por el contrario, en el desarrollo denas de texto puede ser esencial para 


de un juego se hace uso de una clase de esta ca- mejorar el frame rate del juego. 


racterísticas, es importante considerar los siguien- 
tes aspectos: 


= Realizar un estudio del impacto en complejidad espacial y temporal que tiene la 
adopción de una determinada implementación. 


= Informar al equipo de desarrollo de la opción elegida para tener una perspectiva 
global de dicho impacto. 


= Realizar un estudio de la opción elegida considerando aspectos específicos, como 
por ejemplo si todos los buffers son de sólo-lectura. 


En el ámbito del desarrollo de videojuegos, la identificación de entidades o elemen- 
tos está estrechamente ligada con el uso de cadenas de texto. Desde un punto de vista 
general, la identificación unívoca de objetos en el mundo virtual de un juego es una parte 
esencial en el desarrollo como soporte a otro tipo de operaciones, como por ejemplo la lo- 
calización de entidades en tiempo de ejecución por parte del motor de juegos. Así mismo, 
las entidades más van allá de los objetos virtuales. En realidad, también abarcan mallas 
poligonales, materiales, texturas, luces virtuales, animaciones, sonidos, etcétera. 


En este contexto, las cadenas de texto representan la manera más natural de llevar 
a cabo dicha identificación y tratamiento. Otra opción podría consistir en manejar una 
tabla con valores enteros que sirviesen como identificadores de las distintas entidadas. 
Sin embargo, los valores enteros no permiten expresar valores semánticos, mientras que 
las cadenas de texto sí. 





Como regla general, pase los objetos de tipo string como referencia y no como valor, 
ya que esto incurriría en una penalización debido al uso de constructores de copia. 
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Debido a la importancia del tratamiento y manipulación de cadenas, las operaciones 
asociadas han de ser eficientes. Desafortunadamente, este criterio no se cumple en el caso 
de funciones como strecmp(). La solución ideal debería combinar la flexibilidad y poder 
descriptivo de las cadenas con la eficiencia de un tipo de datos primitivo, como los enteros. 
Este planteamiento es precisamente la base del esquema que se discute a continuación. 


7.3.3. Hashing de cadenas 


El uso de una estructura asociativa (ver sección 5.4) se puede utilizar para manejar 
de manera eficiente cadenas textuales. La idea se puede resumir en utilizar una estructura 
asociativa en la que la clave sea un valor numérico y la clase sea la propia cadena de texto. 
De este modo, la comparación entre los códigos hash de las cadenas, es decir, los enteros, 
es muy rápida. 

Si las cadenas se almacenan en una tabla hash, entonces el contenido original se pue- 
de recuperar a partir del código hash. Este esquema es especialmente útil en el proceso de 


depuración para mostrar el contenido textual, ya sea de manera directa por un dispositivo 
de visualización o mediante los típicos archivos de log. 





y String id. En el ámbito profesional, el término string id se utiliza comúnmente para 
referirse a la cadena accesible mediante un determinado valor o código hash. 











Una de las principales cuestiones a considerar 
cuando se utilizan este tipo de planteamientos es 


Interning the strin 





El proceso que permite la generación 


de un identificador número a partir de el diseño de la función de hashing. En otras pala- 
una cadena de texto se suele denomi- bras, la función que traduce las claves, representa- 
nar interning, ya que implica, además das normalmente mediante tipos de datos numéri- 


de realizar el hashing, almacenar la ca- 


denaesunadablade sisibilidad global. cos, en valores, representados por cadenas textua- 


les en esta sección. El principal objetivo consiste 
en evitar colisiones, es decir, evitar que dos cadenas distintas tengan asociadas el mismo 
código o clave. Esta última situación se define como perfect hashing y existe una gran 
cantidad de información en la literatura”. 


Respecto a la implementación de un esquema basado en hashing de cadenas, uno de 
los aspectos clave consiste en decidir cuándo llamar a la función de hashing. Desde un 
punto de vista general, la mayoría de los motores de juegos permiten obtener el identi- 
ficador asociado a una cadena en tiempo de ejecución. Sin embargo, es posible aplicar 
algunos trucos para optimizar dicha funcionalidad. Por ejemplo, es bastante común hacer 
uso de macros para obtener el identificador a partir de una cadena para su posterior uso 
en una sentencia switch. 


También es importante tener en cuenta que el resultado de una función de hashing se 
suele almacenar en algún tipo de estructura de datos, en ocasiones global, con el objetivo 
de incrementar la eficiencia en consultas posteriores. Este planteamiento, parecido a un 
esquema de caché para las cadenas textuales, permite mejorar el rendimiento de la aplica- 
ción. El siguiente listado de código muestra una posible implementación que permite el 
manejo de cadenas de texto mediante una estructura de datos global. 





7Se recomienda la visualización del curso Introduction to Algorithms del MIT, en concreto las clases 7 y 8, 
disponible en la web. 
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static Stringld sid_hola = internString("hola"); 
static Stringld sid_mundo = internString("mundo"); 


Mois 


void funcion (Stringld id) ( 
// Más eficiente que... 
// if (id == internString ("hola")) 
if (id == sid_hola) 
Elcitz 
else if (id == sid_mundo) 
TL sóc 


7.4. Configuración del motor 


Debido a la complejidad inherente a un motor de juegos, existe una gran variedad de 
variables de configuración que se utilizan para especificar el comportamiento de deter- 
minadas partes O ajustar cuestiones específicas. Desde un punto de vista general, en la 
configuración del motor se pueden distinguir dos grandes bloques: 


= Externa, es decir, la configuración vinculada al juego, no tanto al motor, que el 
usuario puede modificar directamente. Ejemplos representativos pueden ser la con- 
figuración del nivel de dificultad de un juego, los ajustes más básicos de sonido, 
como el control de volumen, o incluso el nivel de calidad gráfica. 


= Interna, es decir, aquellos aspectos de configuración utilizados por los desarrolla- 
dores para realizar ajustes que afecten directamente al comportamiento del juego. 
Ejemplos representativos pueden ser la cantidad de tiempo que el personaje princi- 
pal puede estar corriendo sin cansarse o la vitalidad del mismo. Este tipo de pará- 
metros permiten completar el proceso de depuración permanecen ocultos al usuario 
del juego. 





Tricks. En muchos juegos es bastante común encontrar trucos que permiten modifi- 

uy car significativamente algunos aspectos internos del juego, como por ejemplo la ca- 
pacidad de desplazamiento del personaje principal. Tradicionalmente, la activación 
de trucos se ha realizado mediante combinaciones de teclas. 











7.4.1. Esquemas típicos de configuración 


Las variables de configuración se pueden definir de manera trivial mediante el uso de 
variables globales o variables miembro de una clase que implemente el patrón singleton. 
Sin embargo, idealmente debería ser posible modificar dichas variables de configuración 
sin necesidad de modificar el código fuente y, por lo tanto, volver a compilar para generar 
un ejecutable. 


Normalmente, las variables o parámetros de configuración residen en algún tipo de 
dispositivo de almacenamiento externo, como por ejemplo un disco duro o una tarjeta de 
memoria. De este modo, es posible almacenar y recuperar la información asociada a la 
configuración de una manera práctica y directa. A continuación se discute brevemente los 
distintas aproximaciones más utilizadas en el desarrollo de videojuegos. 
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En primer lugar, uno de los esquemás típicos de recuperación y almacenamiento de 
información está representado por los ficheros de configuración. La principal ventaja 
de este enfoque es que son perfectamente legibles ya que suelen especificar de manera 
explícita la variable de configuración a modificar y el valor asociada a la misma. En 
general, cada motor de juegos mantiene su propio convenio aunque, normalmente, todos 
se basan en una secuencia de pares clave-valor. Por ejemplo, Ogre3D utiliza la siguiente 
nomenclatura: 


Render System=0penGL Rendering Subsystem 


[OpenGL Rendering Subsystem] 
Display Frequency=56 MHz 
FSAA=0 

Full Screen=N0 

RTT Preferred Mode=FBO 
VSync=No0 

Video Mode= 800 x 600 

sRGB Gamma Conversion=No 


Dentro del ámbito de los ficheros de configuración, los archivos XML representan 
otra posibilidad para establecer los parámetros de un motor de juegos. En este caso, es 
necesario llevar a cabo un proceso de parsing para obtener la información asociada a 
dichos parámetros. 





El lenguaje XML. eXtensible Markup Language es un metalenguaje extensible ba- 
sado en etiquetas que permite la definición de lenguajes específicos de un determina- 

uv do dominio. Debido a su popularidad, existen multitud de herramientas que permiten 
el tratamiento y la generación de archivos bajo este formato. 











Tradicionalmente, las plataformas de juego que sufrían restricciones de memoria, de- 
bido a limitaciones en su capacidad, hacían uso de un formato binario para almacenar 
la información asociada a la configuración. Típicamente, dicha información se almace- 
naba en tarjetas de memoria externas que permitían salvar las partidas guardadas y la 
configuración proporcionada por el usuario de un determinado juego. 


Este planteamiento tiene como principal ventaja la eficiencia en el almacenamiento de 
información. Actualmente, y debido en parte a la convergencia de la consola de sobremesa 
a estaciones de juegos con servicios más generales, la limitación de almacenamiento en 
memoria permanente no es un problema, normalmente. De hecho, la mayoría de consolas 
de nueva generación vienen con discos duros integrados. 


Los propios registros del sistema operativo también se pueden utilizar como soporte 
al almacenamiento de parámetros de configuración. Por ejemplo, los sistemas operativos 
de la familia de Microsoft Windows “proporcionan una base de datos global implementa- 
da mediante una estructura de árbol. Los nodos internos de dicha estructura actúan como 
directorios mientras que los nodos hoja representan pares clave-valor. 


También es posible utilizar la línea de órdenes o incluso la definición de variables de 
entorno para llevar a cabo la configuración de un motor de juegos. 


Finalmente, es importante reflexionar sobre el futuro de los esquemas de almacena- 
miento. Actualmente, es bastante común encontrar servicios que permitan el almacena- 
miento de partidas e incluso de preferencias del usuario en la red, haciendo uso de servi- 
dores en Internet normalmente gestionados por la propia compañía de juegos. Este tipo 
de aproximaciones tienen la ventaja de la redundancia de datos, sacrificando el control de 
los datos por parte del usuario. 
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7.4.2. Caso de estudio. Esquemas de definición. 


Una técnica bastante común que está directamente relacionada con la configuración de 
un motor de juegos reside en el uso de esquemas de definición de datos. Básicamente, la 
idea general reside en hacer uso de algún tipo de lenguaje de programación declarativo, 
como por ejemplo LISP, para llevar a cabo la definición de datos que permitan su posterior 
exportación a otros lenguajes de programación. Este tipo de lenguajes son muy flexibles y 
proporcionan una gran potencia a la hora de definir estructuras de datos. Junto con Fortran, 
LISP es actualmente uno de los lenguajes de programación más antiguos que se siguen 
utilizando comercialmente. Sus orígenes están fuertemente ligados con la Inteligencia 
Artificial y fue pionero de ideas fundamentales en el ámbito de la computación, como los 
árboles, la gestión automática del almacenamiento o el tipado dinámico. 


A continuación se muestra un ejemplo real del videojuego Uncharted: Drake's For- 
tune, desarrollado por Naughty Dog para la consola de sobremesa Playstation 31M, y 
discutido en profundidad en [5]. En dicho ejemplo se define una estructura básica para al- 
macenar las propiedades de una animación y dos instancias vinculadas a un tipo particular 
de animación, utilizando para ello un lenguaje propietario. 


;; Estructura básica de animación. 
(define simple-animation () 
( 


(name string) 

(speed float «default 1.0) 
(fade-in-seconds float default 0.25) 
(fade-out-seconds float ¡default 0.25) 


) 


;5 Instancia específica para andar 
(define-export anim-walk 
(new simple-animation 
:name "walk" 
:speed 1.0 


; Instancia específica para andar rápido. 
(define-export anim-walk-fast 
(new simple-animation 

:name "walk-fast" 

:speed 2.0 


Evidentemente, la consecuencia directa de definir un lenguaje propio de definición 
de datos implica el desarrollo de un compilador específico que sea capaz de generar de 
manera automática código fuente a partir de las definiciones creadas. En el caso de la 
definición básica de animación planteada en el anterior listado de código, la salida de 
dicho compilador podría ser similar a la mostrada a continuación. 
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// Código generado a partir del compilador. 
// Estructura básica de animación. 


struct SimpleAnimation 
const char* m_name; 


float m_speed; 
float m_fadelInSeconds; 
float m_fade0utSeconds; 


$; 


7.5. Fundamentos básicos de concurrencia 
7.5.1. El concepto de hilo 


Los sistemas operativos modernos se basan en el principio de multiprogramación, es 
decir, en la posibilidad de manejar distintos hilos de ejecución de manera simultánea con 
el objetivo de paralelizar el código e incrementar el rendimiento de la aplicación. Un hilo 
está compuesto por un identificador único de hilo, un contador de programa, un conjunto 
de registros y una pila. 


Esta idea también se plasma a nivel de lenguaje de programación. Algunos ejemplos 
representativos son las APIs de las bibliotecas de hilos Pthread, Win32 o Java. Incluso 
existen bibliotecas de gestión de hilos que se enmarcan en capas software situadas sobre 
la capa del sistema operativo, con el objetivo de independizar el modelo de programación 
del propio sistema operativo subyacente. 


Este último planteamiento es uno de los más utilizados en el desarrollo de videojuegos 
con el objetivo de evitar posibles problemas a la hora de portarlos a diversas plataformas. 
Recuerde que en la sección 1.2.3, donde se discutió la arquitectura general de un motor de 
juegos, se justificaba la necesidad de incluir una capa independiente de la plataforma 
con el objetivo de garantizar la portabilidad del motor. Evidentemente, la inclusión de una 
nueva capa software degrada el rendimiento final de la aplicación. 


Es importante considerar que, a diferencia de un proceso, los hilos que pertenecen 
a un mismo proceso comparten la sección de código, la sección de datos y otros recur- 
sos proporcionados por el sistema operativo (ver figura 7.11), como los manejadores de 
los archivos abiertos. Precisamente, esta diferencia con respecto a un proceso es lo que 
supone su principal ventaja a la hora de utilizar un elemento u otro. 


Informalmente, un hilo se puede definir como un proceso ligero que tiene la misma 
funcionalidad que un proceso pesado, es decir, los mismos estados: nuevo, ejecución, 
espera, preparado y terminado. Por ejemplo, si un hilo abre un fichero, éste estará dispo- 
nible para el resto de hilos de una tarea. Las ventajas de la programación multihilo se 
pueden resumir en las tres siguientes: 


= Capacidad de respuesta, ya que el uso de múltiples hilos proporciona un enfoque 
muy flexible. Así, es posible que un hilo se encuentra atendiendo una petición de 
E/S mientras otro continúa con la ejecución de otra funcionalidad distinta. Además, 
es posible plantear un esquema basado en el paralelismo no bloqueante en llamadas 
al sistema, es decir, un esquema basado en el bloqueo de un hilo a nivel individual. 


..., 


= Compartición de recursos, posibilitando que varios hilos manejen el mismo espa- 
cio de direcciones. 
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código datos archivos código datos archivos 


registros | registros | registros 


ist, 
ici pila pila pila 





(a) (b) 


Figura 7.11: Esquema gráfico de los modelos de programación monohilo (a) y multihilo (b). 


= Eficacia, ya que tanto la creación, el cambio de contexto, la destrucción y la libe- 
ración de hilos es un orden de magnitud más rápida que en el caso de los procesos 
pesados. Recuerde que las operaciones más costosas implican el manejo de opera- 
ciones de E/S. Por otra parte, el uso de este tipo de programación en arquitecturas 
de varios procesadores (o núcleos) incrementa enormemente el rendimiento de la 
aplicación. 


7.5.2. El problema de la sección crítica 


El segmento de código en el que un proceso puede modificar variables compartidas 
con otros procesos se denomina sección crítica. Un ejemplo típico en el ámbito de la 
orientación a objetos son las variables miembro de una clase, suponiendo que las ins- 
tancias de la misma pueden atender múltiples peticiones de manera simultánea mediante 
distintos hilos de control. 


Para evitar inconsistencias, una de las ideas 
que se plantean es que cuando un hilo está ejecutan- 
do su sección crítica, ningún otro hilo puede acce- 


Condición de carrera 


Si no se protege adecuadamente la sec- 
ción crítica, distintas ejecuciones de un 


der a dicha sección crítica. Así, si un objeto puede mismo código pueden generar distin- 
manera múltiples peticiones, no debería ser posible tos resultados, generando así una con- 
que un cliente modifique el estado de dicha instan- dición de carrera. 


cia mientras otro intenta leerlo. 


El problema de la sección crítica consiste en diseñar algún tipo de solución para 
garantizar que los elementos involucrados puedan operar sin generar ningún tipo de in- 
consistencia. Una posible estructura para abordar esta problemática se plantea en la figura 
7.12, en la que el código se divide en las siguientes secciones: 


= Sección de entrada, en la que se solicita el acceso a la sección crítica. 


= Sección crítica, en la que se realiza la modificación efectiva de los datos comparti- 
dos. 


= Sección de salida, en la que típicamente se hará explícita la salida de la sección 
crítica. 
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= Sección restante, que comprende el resto del código fuente. 


SECCIÓN _ ENTRADA 
SECCIÓN CRÍTICA 
SECCIÓN SALIDA 


SECCIÓN_RESTANTE 


Figura 7.12: Estructura general del código vinculado a la sección crítica. 


7.6. La biblioteca de hilos de Ice 
7.6.1. Internet Communication Engine 


ICE (Internet Communication Engine) es un middleware de comunicaciones orientado 
a Objetos, es decir, ICE proporciona herramientas, APIs, y soporte de bibliotecas para 
construir aplicaciones distribuidas cliente-servidor orientadas a objetos (ver figura 7.13). 


Una aplicación ICE se puede usar en entornos heterogéneos. Los clientes y los ser- 
vidores pueden escribirse en diferentes lenguajes de programación, pueden ejecutarse en 
distintos sistemas operativos y en distintas arquitecturas, y pueden comunicarse emplean- 
do diferentes tecnologías de red. La tabla 7.2 resume las principales características de 
ICE. 


Los principales objetivos de diseño de IcE son los siguientes: 


= Middleware listo para usarse en sistemas heterogéneos. 


= Proveee un conjunto completo de características que soporten el desarrollo de apli- 
caciones distribuidas reales en un amplio rango de dominios. 


= Es fácil de aprender y de usar. 


= Proporciona una implementación eficiente en ancho de banda, uso de memoria y 
CPU. 


= Implementación basada en la seguridad. 


Para instalar ICE en sistemas operativos Debian GNU/Linux, ejecute los siguientes 
comandos: 


$ sudo apt-get update 
$ sudo apt-get install zeroc-ice35 


En el módulo 4, Desarrollo de Componentes, se estudiarán los aspectos básicos de 
este potente middleware para construir aplicaciones distribuidas. Sin embargo, en la pre- 
sente sección se estudiará la biblioteca de hilos que proporciona ICE para dar soporte a 
la gestión de la concurrencia y al desarrollo multihilo cuando se utiliza el lenguaje de 
programación C++. 
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Nombre Internet Communications Engine (ICE) 

Definido por ZeroC Inc. (http://www. zeroc.com) 

Documentación http://doc.zeroc.com/display/Doc/Home 

Lenguajes C++, Java, C*f, Visual Basic, Python, PHP, Ruby 
Windows, Windows CE, Unix, GNU/Linux, *BSD 

Plataformas ; : 
OSX, Symbian OS, J2RE 1.4 o superior, J2ME 
APIs claras y bien diseñadas 

Destacado Conjunto de servicios muy cohesionados 
Despliegue, persistencia, cifrado... 

Descargas http://zeroc.com/download.html 








Tabla 7.2: ZeroC Ice. Resumen de características. 


El objetivo principal de esta biblioteca es abstraer al desarrollador de las capas inferio- 
res e independizar el desarrollo de la aplicación del sistema operativo y de la plataforma 
hardware subyacentes. De este modo, la portabilidad de las aplicaciones desarrolladas 
con esta biblioteca se garantiza, evitando posibles problemas de incompatibilidad entre 
sistemas operativos. 


7.6.2. Manejo de hilos 


ICE proporciona distintas utilidades para la ges- Thread-safety 


tión de la concurrencia y el manejo de hilos. Res- le ansiada PencOnES EEE 
pecto a este último aspecto, ICE proporciona una dores mediante un pool de hilos con el 
abstracción muy sencilla para el manejo de hilos objetivo de incrementar el rendimiento 
con el objetivo de explotar el paralelismo mediante de la aplicación. El desarrollador es el 
la creación de hilos dedicados. Por ejemplo, sería responsable de gestionar el acceso con- 
] E A A currente a los datos. 

posible crear un hilo específico que atenda las peti- 

ciones de una interfaz gráfica o crear una serie de hilos encargados de tratar con aquellas 
Operaciones que requieren una gran cantidad de tiempo, ejecutándolas en segundo plano. 


En este contexto, ICE proporciona una abstracción de hilo muy sencilla que posibilita 
el desarrollo de aplicaciones multihilo altamente portables e independientes de la plata- 
forma de hilos nativa. Esta abstracción está representada por la clase IceUtil:: Thread. 


Como se puede apreciar en el siguiente listado de código, Thread es una clase abs- 
tracta con una función virtual pura denominada run(). El desarrollador ha de implementar 
esta función para poder crear un hilo, de manera que run() se convierta en el punto de ini- 
cio de la ejecución de dicho hilo. Note que no es posible arrojar excepciones desde esta 
función. El núcleo de ejecución de ICE instala un manejador de excepciones que llama a 
la función ::std::terminate() si se arroja alguna excepción. 


El resto de funciones de Thread son las siguientes: 


= start(), cuya responsabilidad es arrancar al hilo y llamar a la función run(). Es 
posible especificar el tamaño en bytes de la pila del nuevo hilo, así como un valor 
de prioridad. El valor de retorno de start() es un objeto de tipo ThreadControl, el 
cual se discutirá más adelante. 


= getThreadControl(), que devuelve el objeto de la clase ThreadControl asociado al 
hilo. 


= id(), que devuelve el identificador único asociado al hilo. Este valor dependerá del 
soporte de hilos nativo (por ejemplo, POSIX pthreads). 
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Aplicación cliente Aplicación servidora 


Esqueleto 


APIICE Adaptador de objetos 


ICE runtime (cliente) ICE runtime (servidor) 








Figura 7.13: Arquitectura general de una aplicación distribuida desarrollada con el middleware ZeroC IcE. 


= isAlive(), que permite conocer si un hilo está en ejecución, es decir, si ya se llamó 
a start() y la función run() no terminó de ejecutarse. 


= La sobrecarga de los operadores de comparación permiten hacer uso de hilos en 
contenedores de STL que mantienen relaciones de orden. 


Para mostrar cómo llevar a cabo la implementación de un hilo específico a partir de la 
biblioteca de ICE se usará como ejemplo uno de los problemas clásicos de sincronización: 
el problema de los filósofos comensales. 


Básicamente, los filósofos se encuentran comiendo o pensando. Todos comparten una 
mesa redonda con cinco sillas, una para cada filósofo. Cada filósofo tiene un plato indivi- 
dual con arroz y en la mesa sólo hay cinco palillos, de manera que cada filósofo tiene un 
palillo a su izquierda y otro a su derecha. 


Listado 7.17: La clase IceUtil:: Thread 


1 class Thread :virtual public Shared f 

2 public: 

3 

4 // Función a implementar por el desarrollador. 
5 virtual void run () = 0; 

6 

7 ThreadControl start (size_t stBytes = 0); 

8 ThreadControl start (size_t stBytes, int priority); 
9 ThreadControl getThreadControl () const; 

10 bool isAlive () const; 

11 


12 bool operator== (const Threadá) const; 
13 bool operator!= (const Threadá) const; 
14 bool operator< (const Threadá) const; 
15 ); 

16 

17 typedef Handle<Thread> ThreadPtr; 
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Listado 7.18: La clase FilosofoThread 


*tifndef __FILOSOFO _ 
ftdefine __FILOSOFO__ 





1 

2 

3 

4 *tinclude <iostream> 
5 *tinclude <IceUtil/Thread.h> 
6 *tinclude <Palillo.h> 

7 

8 *ftdefine MAX_COMER 3 

9 Htdefine MAX_PENSAR 7 


10 

11 using namespace std; 

12 

13 class FilosofoThread : public IceUtil::Thread f 

14 

15 public: 

16 FilosofoThread (const intá id, Palillo* izq, Palillo x*der); 
17 

18 virtual void run (); 

19 


20 private: 

21 void coger_palillos (); 
22 void dejar_palillos (); 
23 void comer () const; 
24 void pensar () const; 


26 int _id; 
27 Palillo *_pIzq, *_pDer; 
23 y; 


30 Htendif 


Cuando un filósofo piensa, entonces se abstrae del mundo y no se relaciona con ningún 
otro filósofo. Cuando tiene hambre, entonces intenta coger a los palillos que tiene a su 
izquierda y a su derecha (necesita ambos). Naturalmente, un filósofo no puede quitarle un 
palillo a otro filósofo y sólo puede comer cuando ha cogido los dos palillos. Cuando un 
filósofo termina de comer, deja los palillos y se pone a pensar. 


La solución que se discutirá en esta sección se basa en implementar el filósofo como 
un hilo independiente. Para ello, se crea la clase FilosofoThread que se expone en el 
anterior listado de código. 


La implementación de la función run() es trivial a partir de la descripción del enun- 
ciado del problema. 


Listado 7.19: La función FilosofoThread::run() 





1 void 
2 FilosofoThread::run () 
31 
while (true) £ 
coger_palillos(); 
comer(); 
dejar_palillos(); 
pensar(); 
) 
) 


000=30Uupm 


1 


El problema de concurrencia viene determinado por el acceso de los filósofos a los 
palillos, los cuales representan la sección crítica asociada a cada uno de los hilos que 
implementan la vida de un filósofo. En otras palabras, es necesario establecer algún tipo 
de mecanismo de sincronización para garantizar que dos filósofos no cogen un mismo 
palillo de manera simultánea. 
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Figura 7.14: Abstracción gráfica del 


Antes de abordar esta problemática, se mostra- 
rá cómo lanzar los hilos que representan a los cin- 
co filósofos. El siguiente listado de código mues- 
tra el código básico necesario para lanzar los fi- 
lósofos (hilos). Note cómo en la línea (25) se lla- 
ma a la función start() de Thread para comenzar 
la ejecución del mismo. Los objetos de tipo Th- 
readControl devueltos se almacenan en un vector pa- 
ra, posteriormente, unir los hilos creados. Para ello, 
se hace uso de la función join() de la clase Th- 
readControl, tal y como se muestra en la línea 


problema de los filósofos comensa- 1). 
les, donde cinco filósofos piensan y 
comparten cinco palillos para comer. 


7.6.3. Exclusión mutua básica 


El problema de los filósofos plantea la necesidad de algún tipo de mecanismo de 
sincronización básico para garantizar el acceso exclusivo sobre cada uno de los palillos. 
La opción más directa consiste en asociar un cerrojo a cada uno de los palillos de manera 
individual. Así, si un filósofo intenta coger un palillo que está libre, entonces lo cogerá 
adquiriendo el cerrojo, es decir, cerrándolo. Si el palillo está ocupado, entonces el filósofo 


esperará hasta que esté libre. 


Listado 7.20: Creación y control de hilos con Ice 


1 include <IceUtil/Thread.h> 
2 Htinclude <vector> 

3 ¿ftinclude <Palillo.h> 

4 Hftinclude <Filosofo.h> 


5 


6 *define NUM 5 


7 


8 int main (int argc, char x*argv[]) £ 


9 
10 
11 
12 
13 


std: :vector<Palillo*> palillos; 
std: :vector<IceUtil::ThreadControl> threads; 
int i; 


// Se instancian los palillos. 
for (i = 0; i < NUM; i++) 
palillos.push_back(new Palillo); 


// Se instancian los filósofos. 
for (i = 0; i < NUM; d++) € 
// Cada filósofo conoce los palillos 
// que tiene a su izda y derecha. 
IceUtil::ThreadPtr t = 
new FilosofoThread(i, palillos[il, palillos[(i + 1) %NUM]); 
// start sobre hilo devuelve un objeto ThreadControl. 
threads.push_back(t->start()); 
) 


// 'Unión” de los hilos creados. 

std: :vector<IceUtil::ThreadControl>: :iterator it; 

for (it = threads.begin(); it != threads.end(); ++it) 
it->join(); 


return 0; 
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Locking and unlocking. Típicamente, las operaciones para adquirir y liberar un 
uy cerrojo se denominan lock() y unlock(), respectivamente. La metáfora de cerrojo re- 
presenta perfectamente la adquisición y liberación de recursos compartidos. 





ICE proporciona la clase Mutex para modelar esta problemática de una forma sencilla 
y directa. Las funciones miembro más importantes de esta clase son las que permiten 
adquirir y liberar el cerrojo: 


= lock(), que intenta adquirir el cerrojo. Si éste ya estaba cerrado, entonces el hilo 
que invocó a la función se suspende hasta que el cerrojo quede libre. La llamada a 
dicha función retorna cuando el hilo ha adquirido el cerrojo. 


= tryLock(), que intenta adquirir el cerrojo. A diferencia de lock(), si el cerrojo está 
cerrado, la función devuelve false. En caso contrario, devuelve true con el cerrojo 
cerrado. 


= unlock(), que libera el cerrojo. 


Listado 7.21: La clase IceUtil::Mutex 


1 class Mutex ( 

2 public: 

3 Mutex  (); 

4 Mutex  (MutexProtocol p); 
5 -Mutex (); 

6 

7 

8 


void lock () const; 
bool tryLock () const; 
9 void unlock () const; 


11 typedef LockT<Mutex> Lock; 
12 typedef TryLockT<Mutex> TryLock; 
13 ); 


Es importante considerar que la clase Mutex proporciona un mecanismo de exclusión 
mutua básico y no recursivo, es decir, no se debe llamar a lock() más de una vez desde 
un hilo, ya que esto provocará un comportamiento inesperado. Del mismo modo, no se 
debería llamar a unlock() a menos que un hilo haya adquirido previamente el cerrojo 
mediante lock(). En la siguiente sección se estudiará otro mecanismo de sincronización 
que mantiene una semántica recursiva. 


La clase Mutex se puede utilizar para gestionar el acceso concurrente a los palillos. 
En la solución planteada a continuación, un palillo es simplemente una especialización de 
IceUtil::Mutex con el objetivo de incrementar la semántica de dicha solución. 


Listado 7.22: La clase Palillo 


*tifndef __PALILLO 
ftdefine __PALILLO 


*tinclude <IceUtil/Mutex.h> 


class Palillo : public IceUtil::Mutex 4 


1 
2 
3 
4 
5 
6 
7 y; 
8 

9 


Htendif 
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Para que los filósofos puedan utilizar los palillos, habrá que utilizar la funcionali- 
dad previamente discutida, es decir, las funciones lock() y unlock(), en las funciones co- 
ger_palillos() y dejar_palillos(). La solución planteada garantiza que no se ejecutarán dos 
llamadas a lock() sobre un palillo por parte de un mismo hilo, ni tampoco una llamada so- 
bre unlock() si previamente no se adquirió el palillo. 


void 
FilosofoThread: :coger_palillos () 
t 
_pIzq->lock(); 
_pDer->lock(); 
y 


void 
FilosofoThread: :dejar_palillos () 
t 
-pIzq->unlock(); 
_pDer->unlock(); 


) 


La solución planteada es poco flexible debido a que los filósofos están inactivos du- 
rante el periodo de tiempo que pasa desde que dejan de pensar hasta que cogen los dos 
palillos. Una posible variación a la solución planteada hubiera sido continuar pensando 
(al menos hasta un número máximo de ocasiones) si los palillos están ocupados. En esta 
variación se podría utilizar la función tryLock() para modelar dicha problemática. 





Riesgo de interbloqueo. Si todos los filósofos cogen al mismo tiempo el palillo que 
A está a su izquierda se producirá un interbloqueo ya que la solución planteada no 
podría avanzar hasta que un filósofo coja ambos palillos. 











Evitando interbloqueos 


El uso de las funciones lock() y unlock() puede generar problemas importantes si, por 
alguna situación no controlada, un cerrojo previamente adquirido con lock() no se libera 
posteriormente con una llamada a unlock(). El siguiente listado de código muestra esta 
problemática. 


En la línea (5), la sentencia return implica abandonar mi_funcion() sin haber liberado el 
cerrojo previamente adquirido en la línea (6). En este contexto, es bastante probable que se 
genere una potencial situación de interbloqueo que paralizaría la ejecución del programa. 
La generación de excepciones no controladas representa otro caso representativo de esta 
problemática. 


Gestión del deadlock Para evitar este tipo de problemas, la clase Mu- 
A RAR tex proporciona las definiciones de tipo Lock y Try- 


Aunque existen diversos esquemas pa- a a 
Lock, que representan plantillas muy sencillas com- 


ra evitar y recuperarse de un interblo- 


queo, los sistemas operativos moder- puestas de un constructor en el que se llama a lock() 
nos suelen optar por asumir que nunca y tryLock(), respectivamente. En el destructor se 
se producirán, delegando en el progra- llama a unlock() si el cerrojo fue previamente ad- 


mador la implementación de solucio- 


MES sEpuUas, quirido cuando la plantilla quede fuera de ámbito. 


En el ejemplo anterior, sería posible garantizar la 
liberación del cerrojo al ejecutar return, ya que quedaría fuera del alcance de la función. 
El siguiente listado de código muestra la modificación realizada para evitar interbloqueos. 
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Listado 7.24: Potencial interbloqueo 


*tinclude <IceUtil/Mutex.h> 


1 

2 

3 class Test ( 

4 public: 

5 void mi_funcion () £ 
6 _mutex.lock(); 

7 for (int i=0; i< 5; i++) 

8 if (i == 3) return; // Generará un problema... 
9 _mutex.unlock(); 

10 

11 

12 private: 

13 IceUtil::Mutex _mutex; 

14 >; 


16 int main (int argc, char *argv[]) 4 
17 Test t; 

18 t.mi_funcion(); 

19 return 0; 


Listado 7.25: Evitando interbloqueos con Lock 


*tinclude <IceUtil/Mutex.h> 


1 

2 

3 class Test ( 

4 public: 

5 void mi_funcion () 

6 IceUtil: :Mutex: :Lock lock(_mutex); 
7 for (int i= 0; i< 5; i++) 

8 


if (i == 3) return; // Ningún problema... 
9 ) // El destructor de lock libera el cerrojo. 
10 
11 private: 
12 IceUtil: :Mutex _mutex; 
13 ); 





Es recomendable usar siempre Lock y TryLock en lugar de las funciones lock() y 
unlock para facilitar el entendimiento y la mantenibilidad del código. 





7.6.4. Flexibilizando el concepto de mutex 


Ñ Además de proporcionar cerrojos con una se- No olvides... 
mántica no recursiva, ICE también proporciona la dera ena lo pas 
clase IceUtil::RecMutex con el objetivo de que el mente adquirido y llamar a unlock() 
desarrollador pueda manejar cerrojos recursivos. La tantas veces como a lock() para que el 
interfaz de esta nueva clase es exactamente igual cerrojo quede disponible para otro hilo. 
que la clase /ceUtil::Mutex. 
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Sin embargo, existe una diferencia fundamental entre ambas. Internamente, el cerrojo 
recursivo está implementado con un contador inicializado a cero. Cada llamada a lock() 
incrementa el contador, mientras que cada llamada a unlock() lo decrementa. El cerrojo 
estará disponible para otro hilo cuando el contador alcance el valor de cero. 


class RecMutex 4 


public: 

RecMutex  (); 

RecMutex  (MutexProtocol p); 
-RecMutex (); 

void lock () const; 

bool tryLock () const; 

void unlock () const; 


typedef LockT<RecMutex> Lock; 
typedef TryLockT<RecMutex> TryLock; 


7.6.5. Introduciendo monitores 


Tanto la clase Mutex como la clase MutexRec son mecanismos de sincronización bá- 
sicos que permiten que sólo un hilo esté activo, en un instante de tiempo, dentro de la 
sección crítica. En otras palabras, para que un hilo pueda acceder a la sección crítica, otro 
ha de abandonarla. Esto implica que, cuando se usan cerrojos, no resulta posible suspen- 
der un hilo dentro de la sección crítica para, posteriormente, despertarlo cuando se cumpla 
una determinada condición. 


Para tratar este tipo de problemas, la biblioteca de hilos de ICE proporciona la clase 
Monitor. En esencia, un monitor es un mecanismo de sincronización de más alto nivel 
que, al igual que un cerrojo, protege la sección crítica y garantiza que solamente pueda 
existir un hilo activo dentro de la misma. Sin embargo, un monitor permite suspender un 
hilo dentro de la sección crítica posibilitando que otro hilo pueda acceder a la misma. 
Este segundo hilo puede abandonar el monitor, liberándolo, o suspenderse dentro del 
monitor. De cualquier modo, el hilo original se despierta y continua su ejecución dentro 
del monitor. Este esquema es escalable a múltiples hilos, es decir, varios hilos pueden 
suspenderse dentro de un monitor. 


Desde un punto de vista general, los monitores proporcionan un mecanismo de sin- 
cronización más flexible que los cerrojos, ya que es posible que un hilo compruebe una 
condición y, si ésta es falsa, el hilo se pause. Si otro hilo cambia dicha condición, entonces 
el hilo original continúa su ejecución. 


El siguiente listado de código muestra la declaración de la clase IceUtil::Monitor. 
Note que se trata de una clase que hace uso de plantillas y que requiere como parámetro 
bien Mutex o RecMutex, en función de si el monitor mantendrá una semántica no recursiva 
O recursiva, respectivamente. 





Solución de alto nivel. Las soluciones de alto nivel permiten que el desarrollador 
tenga más flexibilidad a la hora de solucionar un problema. Este planteamiento se 
aplica perfectamente al uso de monitores. 
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Datos 
compartidos 


Operaciones 


inicialización 


Figura 7.15: Representación gráfica del concepto de monitor. 


Listado 7.27: La clase IceUtil::Monitor 





template <class T> 
class Monitor 4 


public: 
void lock () const; 
void unlock () const; 


bool tryLock () const; 


void wait () const; 

bool timedWait (const Time“) const; 
void notify (); 

void notifyAll (); 


typedef LockT<Monitor<T> > Lock; 
typedef TryLockT<Monitor<T> > TryLock; 


y; 


Las funciones miembro de esta clase son las siguientes: 


lock(), que intenta adquirir el monitor. Si éste ya estaba cerrado, entonces el hilo 
que la invoca se suspende hasta que el monitor quede disponible. La llamada retorna 
con el monitor cerrado. 


tryLock(), que intenta adquirir el monitor. Si está disponible, la llamada devuelve 
true con el monitor cerrado. Si éste ya estaba cerrado antes de relizar la llamada, la 
función devuelve false. 


unlock(), que libera el monitor. Si existen hilos bloqueados por el mismo, entonces 
uno de ellos se despertará y cerrará de nuevo el monitor. 


wait(), que suspende al hilo que invoca a la función y, de manera simultánea, libera 
el monitor. Un hilo suspendido por wait() se puede despertar por otro hilo que invo- 
que a la función notify() o notifyAll(). Cuando la llamada retorna, el hilo suspendido 
continúa su ejecución con el monitor cerrado. 


timedWait(), que suspende al hilo que invoca a la función hasta un tiempo espe- 
cificado por parámetro. Si otro hilo invoca a notify() o notifyAll() despertando al 
hilo suspendido antes de que el timeout expire, la función devuelve true y el hilo 
suspendido resume su ejecución con el monitor cerrado. En otro caso, es decir, si 
el timeout expira, timedWait() devuelve false. 
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= notify(), que despierta a un único hilo suspendido debido a una invocación sobre 
wait() o timedWait(). Sino existiera ningún hilo suspendido, entonces la invocación 
sobre notify() se pierde. Llevar a cabo una notificación no implica que otro hilo 
reanude su ejecución inmediatamente. En realidad, esto ocurriría cuando el hilo 
que invoca a wait() o timedWait() libera el monitor. 


= notifyAll(), que despierta a todos los hilos suspendidos por wait() o timedWait(). El 
resto del comportamiento derivado de invocar a esta función es idéntico a notify(). 





A No olvides... Comprobar la condición asociada al uso de wait siempre que se retorne 
de una llamada a la misma. 











Ejemplo de uso de monitores 


Imagine que desea modelar una situación en un videojuego en la que se controlen 
los recursos disponibles para acometer una determinada tarea. Estos recursos se pueden 
manipular desde el punto de vista de la generación o producción y desde el punto de vista 
de la destrucción o consumición. En otras palabras, el problema clásico del productor/- 
consumidor. 


Por ejemplo, imagine un juego de acción de tercera persona en el que el personaje 
es capaz de acumular slots para desplegar algún tipo de poder especial. Inicialmente, el 
personaje tiene los slots vacíos pero, conforme el juego evoluciona, dichos slots se pueden 
rellenar atendiendo a varios criterios independientes. Por ejemplo, si el jugador acumula 
una cantidad determinada de puntos, entonces obtendría un slot. Si el personaje principal 
vence a un enemigo con un alto nivel, entonces obtendría otro slot. Por otra parte, el 
jugador podría hacer uso de estas habilidades especiales cuando así lo considere, siempre 
y cuando tenga al menos un slot relleno. 


Este supuesto plantea la problemática de sincronizar 
el acceso concurrente a dichos slots, tanto para su consu- 
mo como para su generación. Además, hay que tener en 
cuenta que sólo será posible consumir un slot cuando ha- 
ya al menos uno disponible. Es decir, la problemática dis- 
cutida también plantea ciertas restricciones o condiciones 
que se han de satisfacer para que el jugador pueda lanzar 
una habilidad especial. 


Oy 


Y 
E 


En este contexto, el uso de los monitores proporcio- 
na gran flexibilidad para modelar una solución a este su- 
puesto. El siguiente listado de código muestra una posible 
implementación de la estructura de datos que podría dar 
soporte a la solución planteada, haciendo uso de los mo- 
nitores de la biblioteca de hilos de ICE. 


Y 
g 


CH 


Os 





Ñ [AS Como se puede apreciar, la clase definida es un tipo 
particular de monitor sin semántica recursiva, es decir, de- 
finido a partir de /ceUtil::Mutex. Dicha clase tiene como 

Figura 7.16: En los juegos arcade variable miembro una cola de doble entrada que maneja 

de aviones, los poderes especiales se vor dedatos PA ll definidak 

suelen representar con cohetes para p A genéricos, ya que a Clase de ni a hace uso 

denotar la potencia de los mismos. de una plantilla. Además, esta clase proporciona las dos 
Operaciones típicas de put() y get() para añadir y obtener 
elementos. Hay, sin embargo, dos características impor- 

tantes a destacar en el diseño de esta estructura de datos: 
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Figura 7.17: Representación gráfica del uso de un monitor. 


Listado 7.28: Utilizando monitores 





1 *tinclude <IceUtil/Monitor.h> 

2 *tinclude <IceUtil/Mutex.h> 

3 ¿*tinclude <deque> 

4 

5 using namespace std; 

6 

7 template<class T> 

8 class Queue : public IceUtil::Monitor<IceUtil::Mutex> ( 


9 public: 

10 void put (const T6 item) (£ // Añade un nuevo item. 
11 TceUtil: :Monitor<IceUtil::Mutex>: :Lock lock(*this); 
12 —queue.push_back(item); 

13 notify(); 

14 , 

15 

16 T get () £ // Consume un item. 

17 TceUtil::Monitor<IceUtil::Mutex>::Lock lock(*this); 
18 while (_queue.size() == 0) 

19 wait (); 

20 T item = _queue.front(); 

21 —queue.pop_front(); 

22 return item; 

23 

24 


25 private: 
26 deque<T> _queue; // Cola de doble entrada. 
27 y; 


1. El acceso concurrente a la variable miembro de la clase se controla mediante el 
propio monitor, haciendo uso de la función lock() (líneas (11) y (17). 


2. Si la estructura no contiene elementos, entonces el hilo se suspende mediante wait() 
(líneas (18-19)) hasta que otro hilo que ejecute put() realice la invocación sobre no- 


tify() línea (13). 
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Recuerde que para que un hilo bloqueado por wait() reanude su ejecución, otro hilo 
ha de ejecutar notify() y liberar el monitor mediante unlock(). Sin embargo, en el anterior 
listado de código no existe ninguna llamada explícita a unlock(). ¿Es incorrecta la solu- 
ción? La respuesta es no, ya que la liberación del monitor se delega en Lock cuando la 
función put() finaliza, es decir, justo después de ejecutar la operación notify() en este caso 
particular. 





No olvides... Usar Lock y TryLock para evitar posibles interbloqueos causados por la 
generación de alguna excepción o una terminación de la función no prevista inicial- 
mente. 





Volviendo al ejemplo anterior, considere dos hilos distintos que interactúan con la es- 
tructura creada, de manera genérica, para almacenar los slots que permitirán la activación 
de habilidades especiales por parte del jugador virtual. Por ejemplo, el hilo asociado al 
productor podría implementarse como se muestra en el siguiente listado. 


class Productor : public IceUtil:: Thread ( 


public: 
Productor (Queue<string> *_q): 
-queue(-q) (+ 
void run () £ 


for (int i=0; 1 < 5; i++) £ 
IceUtil: :ThreadControl: :sleep 

(IceUtil: :Time: :seconds(rand() %7)); 
—queue->put ("TestSlot"); 

y 


private: 
Queue<string> *_queue; 


y; 


Suponiendo que el código del consumidor sigue la misma estructura, pero extrayen- 
do elementos de la estructura de datos compartida, entonces sería posible lanzar distintos 
hilos para comprobar que el acceso concurrente sobre los distintos slots se realiza de 
manera adecuada. Además, sería sencillo visualizar, mediante mensajes por la salida es- 
tándar, que efectivamente los hilos consumidores se suspenden en wait() hasta que hay al 
menos algún elemento en la estructura de datos compartida con los productores. 


Antes de pasar a discutir en la sección 7.9 un caso de estudio para llevar a cabo el 
procesamiento de alguna tarea en segundo plano, resulta importante volver a discutir la 
solución planteada inicialmente para el manejo de monitores. En particular, la implemen- 
tación de las funciones miembro put() y get() puede generar sobrecarga debido a que, 
cada vez que se añade un nuevo elemento a la estructura de datos, se realiza una invo- 
cación. Si no existen hilos esperando, la notificación se pierde. Aunque este hecho no 
conlleva ningún efecto no deseado, puede generar una reducción del rendimiento si el 
número de notificaciones se dispara. 
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Una posible solución a este problema consiste en llevar un control explícito de la 
existencia de consumidores de información, es decir, de hilos que invoquen a la función 
get(). Para ello, se puede incluir una variable miembro en la clase Queue, planteando un 
esquema mucho más eficiente. 


Información adicional Como se puede apreciar en el siguiente listado 
A a de código, el hilo productor sólo llevará a cabo una 
Una vez el más, el uso de alguna es- : de as 

tructura de datos adicional puede faci- notificación en el caso de que haya algún hilo con- 
litar el diseño de una solución. Este ti- sumidor en espera. Para ello, consulta el valor de la 
po de planteamientos puede incremen- variable miembro _consumidoresEsperando. 

tar la eficiencia de la solución plantea- . Ñ . 
da aunque haya una mínima sobrecarga Por otra parte, los hilos consumidores, es decir, 
debido al uso y procesamiento de datos los que invoquen a la función get() incrementan di- 
extra. cha variable antes de realizar un wait(), decremen- 


tándola cuando se despierten. 


Note que el acceso a la variable miembro _consumidoresEsperando es exclusivo y se 
garantiza gracias a la adquisición del monitor justo al ejecutar la operación de generación 
o consumo de información por parte de algún hilo. 


Listado 7.30: Utilizando monitores (11) 


1 *tinclude <IceUtil/Monitor.h> 

2 *tinclude <IceUtil/Mutex.h> 

3 ¿*tinclude <deque> 

4 using namespace std; 

5 

6 template<class T> 

7 class Queue : public IceUtil::Monitor<IceUtil::Mutex> ( 


8 public: 

9 Queue () : _consumidoresEsperando(0) (7 

10 

11 void put (const T€ item) [£ // Añade un nuevo item. 
12 TceUtil: :Monitor<IceUtil::Mutex>: :Lock lock(*this); 
13 —queue.push_back(item); 

14 if (_consumidoresEsperando) notify(); 

15 y 

16 

17 T get () £ // Consume un item. 

18 TceUtil::Monitor<IceUtil::Mutex>::Lock lock(*this); 
19 while (_queue.size() == 0) £ 

20 try £ 

21 _consumidoresEsperando++; 

22 wait(); 

23 _consumidoresEsperando--; 

24 , 

25 catch (...) £ 

26 _consumidoresEsperando--; 

27 throw; 

28 , 

29 J 

30 T item = _queue.front(); 

31 _queue.pop_front(); 

32 return item; 

33 

34 


35 private: 

36 deque<T> _queue; // Cola de doble entrada. 
37 int _consumidoresEsperando; 

38 )P; 


[270] Capítulo 7 :: Bajo Nivel y Concurrencia 





7.7. Concurrencia en C++11 
Una de las principales mejoras aportadas por C++11 es el soporte a la programación 


concurrente. De hecho, la creación de hilos resulta trivial, gracias a la clase Thread*, y 
sigue la misma filosofía que en otras bibliotecas más tradicionales (como pthread): 


Listado 7.31: Uso básico de la clase Thread 


1 include <iostream> 


2 *tinclude <thread> 

3 using namespace std; 

4 

5 void func (int x) 4 

6 cout << "Dentro del hilo " << x << endl; 
O 

8 

9 int main() £ 

10 thread th(4func, 100); 

11 th.join(); 

12 cout << "Fuera del hilo" << endl; 
13 return 0; 

14 y 


Para poder compilar este programa con la última versión del estándar puede utilizar 
el siguiente comando: 


$ g++ -std=c++11 Thread_c++11.cpp -o Thread -pthread 


El concepto de mutex? como mecanismo básico de exclusión mutua también está 
contemplado por el lenguaje y permite acotar, de una manera sencilla y directa, aquellas 
partes del código que solamente deben ejecutarse por un hilo en un instante de tiempo 
(sección crítica). Por ejemplo, el siguiente fragmento de código muestra cómo utilizar un 
mutex para controlar el acceso exclusivo a una variable compartida por varios hilos: 


Listado 7.32: Uso básico de la clase Mutex 


int contador = 0; 
mutex contador_mutex; 


1 

2 

3 

4 void anyadir_doble (int x) 4 
5 int tmp = 2 * x; 

6 contador_mutex.lock(); 

7 contador += tmp; 

8 contador_mutex.unlock(); 
9 


C++11 ofrece incluso mecanismos que facilitan y simplifican el código de manera 
sustancial. Por ejemplo, la funcionalidad asociada al listado anterior se puede obtener, de 
manera alternativa, mediante el contenedor atomic: 





Shttp://es .Cppreference.com/w/cpp/thread 
Ihttp://es .Cppreference.com/w/cpp/thread/mutex 
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Listado 7.33: Utilizando el contenedor atomic 





Htinclude <atomic> 
atomic<int> contador(0); 


void anyadir_doble (int x) ( 


1 
2 
3 
4 
5 
6 contador += 2 * x; 
7 


J 


7.7.1. Filósofos comensales en C++11 


En esta sección se discutirá una posible implementación del problema de los filósofos 
comensales utilizando la funcionalidad proporcionada, desde el punto de vista de la pro- 
gramación concurrente, de C++11. Así mismo, también se introducirá el uso de algunas 
de las mejoras que incluye esta nueva versión del estándar, las cuales se discutirán con 
mayor profundidad en el módulo 3, Técnicas Avanzadas de Desarrollo. 


El siguiente listado de código muestra la implementación de la clase Palillo. A di- 
ferencia del esquema planteado en la sección 7.6.3, esta implementación se basa en la 
composición en lugar de herencia con el objetivo de discutir las diferencias existentes 
entre ambos enfoques a la hora de manipular mutex. En principio, la primera opción a 
considerar debería ser la composición, es decir, un esquema basado en incluir una va- 
riable miembro de tipo mutex dentro de la declaración de la clase asociada al recurso 
compartido. Recuerde que las relaciones de herencia implican fuertes restricciones desde 
el punto de vista del diseño y se deberían establecer cuidadosamente. 


Listado 7.34: Filósofos comensales en C++11 (Palillo) 


1 class Palillo Y 
2 public: 

3 mutex _mutex; 
4 y; 


A continuación se muestra la función comer(), la cual incluye la funcionalidad aso- 
ciada a coger los palillos. Note cómo esta función lambda o función anónima se define 
dentro del propio código de la función main (en línea) y propicia la generación de un 
código más claro y directo. Además, el uso de auto oculta la complejidad asociada al 
manejo de punteros a funciones. 


Esta función recibe como argumentos (líneas (4-5)) apuntadores a dos palillos, junto a 
sus identificadores, y el identificador del filósofo que va a intentar cogerlos para comer. 
En primer lugar, es interesante resaltar el uso de std::lock sobre los propios palillos en 
la línea (7) para evitar el problema clásico del interbloqueo de los filósofos comensales. 
Esta función hace uso de un algoritmo de evasión del interbloqueo y permite adquirir dos 
o más mutex mediante una única instrucción. Así mismo, también se utiliza el wrapper 
lock_guard (líneas (12) y (7) con el objetivo de indicar de manera explícita que los mutex 
han sido adquiridos y que éstos deben adoptar el propietario de dicha adquisición. 


El resto del código de esta función muestra por la salida estándar mediante std::cout 
mensajes que indican el filósofo ha adquirido los palillos. 


Una vez definida la funcionalidad general asociada a un filósofo, el siguiente paso 
consiste en instanciar los palillos a los propios filósofos. 


[272] Capítulo 7 :: Bajo Nivel y Concurrencia 


Listado 7.35: Filósofos comensales en C++11 (Función comer) 


1 int main () 4 

2 /* Función lambda (función anónima) */ 

3 /* Adiós a los punteros a funciones con auto */ 

4 auto comer = [](Palillo* pIzquierdo, Palillox* pDerecho, 
5 

6 

7 

8 





int id filosofo, int id pIzquierdo, int id _pDerecho) f 
/* Para evitar interbloqueos */ 
lock(pIzquierdo->_mutex, pDerecho->_mutex) ; 


9 /* Wrapper para adquirir el mutex en un bloque de código */ 
10 /* Indica que el mutex ha sido adquirido y que debe 

11 adoptar al propietario del cierre */ 

12 lock_guard<mutex> izquierdo(pIzquierdo->_mutex, adopt_lock); 
13 string si = "MtFilósofo " + to_string(id filosofo) + 

14 " cogió el palillo " + to_string(id_plzquierdo) + ".Wn"; 
15 cout << si.c_str(); 

16 

17 lock_guard<mutex> derecho(pDerecho->_mutex, adopt_lock); 

18 string sd = "YtFilósofo " + to_string(id_filosofo) + 

19 " cogió el palillo " + to_string(id_pDerecho) + ".An"; 
20 cout << sd.c_str(); 

21 

22 string pe = "Filósofo " + to_string(id_filosofo) + " come.IAn"; 
23 cout << pe; 

24 

25 std: :chrono: :milliseconds espera(1250); 

26 std::this_thread: :sleep_for(espera); 

27 

28 /* Los mutex se desbloquean al salir de la función */ 

29 F; 


El listado que se muestra a continuación lleva a cabo la instanciación de los palillos 


(ver línea (9). Éstos se almacenan en un contenedor vector que inicialmente tiene una 
capacidad igual al número de filósofos (línea (1). Resulta interesante destacar el uso de 
unique_ptr en la línea 4 para que el programador se olvide de la liberación de los punteros 
asociados, la cual tendrá lugar, gracias a este enfoque, cuando queden fuera del ámbito de 
declaración. También se utiliza la función std::move en la línea (12), novedad en C++11, 
para copiar el puntero a p1 en el vector palillos, anulándolo tras su uso. 


Listado 7.36: Filósofos comensales en C++11 (Creación palillos) 


1 static const int numero_filosofos = 5; 


3 /* Vector de palillos */ 
4 vector< unique_ptr<Palillo> > palillos(numero_filosofos); 


5 
6 for (int i= 0; i < numero_filosofos; i++) 4 

7 /* El compilador infiere el tipo de la variable :-) */ 

8 /* unique_ptr para destrucción de objetos fuera del scope */ 
9 auto pl = unique _ptr<Palillo>(new Palillo()); 

10 /* move copia cl en la posición adecuada de palillos y 


11 lo anula para usos posteriores */ 
12 palillos[il = move(p1); 
13 ) 


Finalmente, el código restante que se expone a continuación es el responsable de la 
instanciación de los filósofos. Estos se almacenan en un vector que se instancia en la 
línea (2), el cual se rellena mediante un bucle for a partir de la línea (20). Sin embargo, 
antes se inserta el filósofo que tiene a su derecha el primer palillo y a su izquierda el 


último (líneas (6-17). 
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Note cómo en cada iteración de este bucle se crea un nuevo hilo, instanciando la 
clase thread (línea (21). Cada instancia de esta clase maneja un apuntador a la función 
comer, la cual recibe como argumentos los apuntadores a los palillos que correspondan 
a cada filósofo y los identificadores correspondientes para mostrar por la salida estándar 
los mensajes reflejan la evolución de la simulación. 


La última parte del código, en las líneas (32-34), lleva a cabo la ejecución efectiva de 
los hilos y la espera a la finalización de los mismos mediante la función thread: :join(). 


Listado 7.37: Filósofos comensales en C++11 (Creación filósofos) 


1 /x* Vector de filósofos */ 

2 vector<thread> filosofos(numero_filosofos); 

3 

4 /x* Primer filósofo x*/ 

5 /x A su derecha el palillo 1 y a su izquierda el palillo 5 */ 
6 filosofos[0] = thread(comer, 


7 /* Palillo derecho (1) */ 
8 palillos[0].get(), 

9 /x* Palillo izquierdo (5) x*/ 
10 palillos[numero_filosofos - 1].get(), 
11 /* Id filósofo */ 

12 1, 

13 /x* Id palillo derecho x/ 

14 LT; 

15 /* Id palillo izquierdo x*/ 
16 numero_filosofos 

17 y; 

18 


19 /x* Restos de filósofos */ 
20 for (int i= 1; i < numero_filosofos; i++) 4 


21 filosofos[il = (thread(comer, 

22 palillos[i - 1].get(), 
23 palillos[il.get(), 

24 iz+l, 

25 A; 

26 i+1 

27 ) 

28 e 

29 ) 

30 


31 /* A comer... */ 

32 for_each(filosofos.begin(), 
33 filosofos.end(), 

34 mem_fn(Gthread: :join)); 


7.8. Multi-threading en Ogre3D 


Desde un punto de vista general, la posible integración de hilos de ejecución adiciona- 
les con respecto al núcleo de ejecución de Ogre se suele plantear con aspectos diferentes 
al meramente gráfico. De hecho, es poco común que el proceso de rendering se delegue en 
un segundo plano debido a la propia naturaleza asíncrona de la GPU (Graphic Processing 
Unit). 


Por lo tanto, no existe una necesidad real de utilizar algún esquema de sincronización 
para evitar condiciones de carrera o asegurar la exclusión mutua en determinadas partes 
del código. 
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Sin embargo, sí que es posible delegar en un segun- 
do plano aspectos tradicionalmente independientes de la 
parte gráfica, como por ejemplo el módulo de Inteligen- 
cia Artificial o la carga de recursos. En esta sección, se 
discutirán las características básicas que Ogre3D ofrece 
para la carga de recursos en segundo plano. 


En primer lugar, puede ser necesario compilar Ogre 
con soporte para multi-threading, típicamente soportado 
por la biblioteca boost. Para ejemplificar este problema, a 
continuación se detallan las instrucciones para compilar 


Figura 7.18: Ogre proporciona me- el código fuente de Ogre 1.8.1'%. 
canismos para llevar a cabo la carga . . 
de recursos en segundo plano. Antes de nada, es necesario asegurarse de que la bi- 


blioteca de hilos de boost está instalada y es recomenda- 

ble utilizar cmake para generar el Makefile que se utiliza- 
rá para compilar el código fuente. Para ello, en sistemas operativos Debian GNU/Linux y 
derivados, hay que ejecutar los siguientes comandos: 





$ sudo apt-get install libboost-thread-dev 
$ sudo apt-get install cmake cmake-qt-gui 


A continuación, es necesario descomprimir el código de Ogre y crear un directorio en 
el que se generará el resultado de la compilación: 


$ tar xjf ogre_src_v1-8-1.tar.bz2 
$ mkdir ogre_build_v1-8-1 


El siguiente paso consiste en ejecutar la interfaz gráfica que nos ofrece cmake para 
hacer explícito el soporte multi-hilo de Ogre. Para ello, simplemente hay que ejecutar el 
comando cmake-gui y, a continuación, especificar la ruta en la que se encuentra el código 
fuente de Ogre y la ruta en la que se generará el resultado de la compilación, como se 
muestra en la figura 7.19. Después, hay que realizar las siguientes acciones: 


1. Hacer click en el botón Configure. 
2. Ajustar el parámetro OGRE_CONFIG_THREADS"'. 
3. Hacer click de nuevo en el botón Configure. 


4, Hacer click en el botón Generate para generar el archivo Makefile. 


Es importante recalcar que el parámetro OGRE_CONFIG_THREADS establece el 
tipo de soporte de Ogre respecto al modelo de hilos. Un valor de O desabilita el soporte 
de hilos. Un valor de 1 habilita la carga completa de recursos en segundo plano. Un valor 


de 2 activa solamente la preparación de recursos en segundo plano”?. 
Finalmente, tan sólo es necesario compilar y esperar a la generación de todos los eje- 


cutables y las bibliotecas de Ogre. Note que es posible optimizar este proceso indicando 
el número de procesadores físicos de la máquina mediante la opción —j de make. 


$ cd ogre_build_v1-8-1 
$ make -j 2 





http ://www.ogre3d.org/download/source 
11 http: //ww.ogre3d.org/tikiwiki/tiki-index.php?page=Building+0gre+With+CMake 
12Según los desarrolladores de Ogre, sólo se recomienda utilizar un valor de O o de 2 en sistemas GNU/Linux 
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'cMake 2.8.9 - /home/david/apps/ogre3 d/ogre-build.v1-8-1 


File Tools Options Help 





Where is the source code: [/nome/david/apps/ogre3d/ogre-sre-v1-8-1 | | Browse Source... | 








Where to build the binaries: [/home/david/apps/ogre3d/ogre-build-v1-8-1 | No | Browse Build... | 








Search: O Grouped [] Advanced ES Add Entry || Remove Entry 








Name Value 











Press Configure to update and display new values in red, then press Generate to generate selected build files. 





Configure | | Generate | Current Generator: Unix Makefiles 











Configuring dones 


e | 














Figura 7.19: Generando el fichero Makefile mediante cmake para compilar Ogre 1.8.1. 


Para ejemplificar la carga de recursos en segundo plano, se retomará el ejemplo dis- 
cutido en la sección 6.2.2. En concreto, el siguiente listado de código muestra cómo se ha 
modificado la carga de un track de música para explicitar que se haga en segundo plano. 


Como se puede apreciar, en la línea (13) se hace uso de la función setBackgroundLoa- 
ded() con el objetivo de indicar que el recurso se cargará en segundo plano. 


A continuación, en la siguiente línea, se añade un objeto de la clase MyListener, la 
cual deriva a su vez de la clase Ogre::Resource::Listener para controlar la notificación 
de la carga del recurso en segundo plano. 





Callbacks. El uso de funciones de retrollamada permite especificar el código que se 
(5) ejecutará cuando haya finalizado la carga de un recurso en segundo plano. A partir 
de entonces, será posible utilizarlo de manera normal. 











En este ejemplo se ha sobreescrito la función backgroundLoadingComplete() que per- 
mite conocer cuándo se ha completado la carga en segundo plano del recurso. La docu- 
mentación relativa a la clase Ogre::Resource::Listener!? discute el uso de otras funciones 
de retrollamada que resultan útiles para cargar contenido en segundo plano. 





http ://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_resource.html 
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Listado 7.38: Carga en segundo plano de un recurso en Ogre 


1 
2 
3 
4 


wo =30oNu 


10 


12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 


TrackPtr 
TrackManager: :load 


(const Ogre: :Stringé name, const Ogre: :Stringá group) 


1 


// Obtención del recurso por nombre... 
TrackPtr trackPtr = getByName (name) ; 


// Si no ha sido creado, se crea. 
if (trackPtr.isNull()) 
trackPtr = create(name, group); 


// Carga en segundo plano y listener. 
trackPtr->setBackgroundLoaded (true); 
trackPtr->addListener(new MyListener); 


// Escala la carga del recurso en segundo plano. 


if (trackPtr->isBackgroundLoaded()) 
trackPtr->escalateLoading(); 

else 
trackPtr->load(); 


return trackPtr; 


Otra posible variación en el diseño podría haber consistido en delegar la notificación 


de la función de retrollamada a la propia clase TrackPtr, es decir, que esta clase heredase 
de Ogre::Resource::Listener. 


Listado 7.39: Clase MyListener 


1 


11 
12 
13 
14 
15 
16 
17 


*tifndef __MYLISTENERH__ 
itdefine __MYLISTENERH__ 


*tinclude <0GRE/OgreResource.h> 
*tinclude <iostream> 


using namespace std; 


class MyListener 


public Ogre: :Resource: :Listener £ 


void backgroundLoadingComplete (Ogre::Resourcex r) 4 
cout << "Carga en segundo plano completada..." << endl; 


y; 


Htendif 
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7.9. Caso de estudio. Procesamiento en segundo plano 
mediante hilos 


En esta sección se discute cómo llevar a cabo un procesamiento adicional al hilo de 
control manejado por Ogre. Para ello, se hace uso de las herramientas proporcionadas por 
la biblioteca de hilos de ZeroC Ice, estudiadas en las secciones anteriores. 


En concreto, el problema que se plantea consiste en 
diseñar e implementar un sencillo módulo de Inteligen- OS O 
cia Artificial para un juego de tipo Simon!*, el cual será PT , 
el responsable de la generación de las distintas secuencias 
de juego. Más allá de la complejidad del módulo de IA, 
resulta más interesante en este punto afrontar el problema 
de la creación y gestión de hilos de control adicionales. 
En el módulo 4, Desarrollo de Componentes, se discuten A : 
diversas técnicas de IA que se pueden aplicar a la hora de — FW 
implementar un juego. 





Figura 7.20: Aspecto gráfico de un 
Antes de pasar a discutir la implementación plantea- juego tipo Simon. 


da, recuerde que en el juego Simon el jugador ha de ser 

capaz de memorizar y repetir una secuencia de colores generada por el dispositivo de jue- 
go. En este contexto, el módulo de IA sería el encargado de ir generando la secuencia a 
repetir por el jugador. 


El siguiente listado de código muestra la declaración del hilo dedicado al módulo de 
TA. Como se puede apreciar, la clase AlThread hereda de IceUtil::Thread. Las variables 
miembro de esta clase son las siguientes: 


= _delay, que mantiene un valor temporal utilizado para dormir al módulo de TA 
entre actualizaciones. 


= _mutex, que permite controlar el acceso concurrente al estado de la clase. 


= _seq, que representa la secuencia de colores, mediante valores enteros, generada 
por el módulo de IA. 


En la solución planteada se ha optado por utilizar el mecanismo de exclusión mutua 
proporcionado por ICE para sincronizar el acceso concurrente al estado de AlThread con 
un doble propósito: 1) ilustrar de nuevo su utilización en otro ejemplo y 1i) recordar que 
es posible que distintos hilos de control interactúen con el módulo de IA. 


Note cómo en la línea (23) se ha definido un manejador para las instancias de la clase 
AlThread utilizando IceUtil::Handle con el objetivo de gestionar de manera inteligente 
dichas instancias. Recuerde que la función miembro run() especificará el comportamiento 
del hilo y es necesario implementarla debido al contracto funcional heredado de la clase 
Ice Util::Thread. 





Updating threads... Idealmente, el módulo de IA debería aprovechar los recursos 
a disponibles, no utilizados por el motor de rendering, para actualizar su estado. Ade- 
más, se debería contemplar la posibilidad de sincronización entre los mismos. 














Ye http://code.google.com/p/videojuegos- 2011-12 
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*Htifndef __AI__ 
ítdefine __AI__ 


*tinclude <IceUtil/IceUtil.h> 
ttinclude <vector> 


class AlThread : public IceUtil::Thread [ 


public: 

AlThread (const IceUtil:: Times delay); 
int getColorAt (const inté index) const; 
void reset (); 

void update (); 


virtual void run (); 


private: 
IceUtil::Time _delay; // Tiempo entre actualizaciones. 
IceUtil::Mutex _mutex; // Cerrojo para acceso exclusivo. 
std: :vector<int> _seq; // Secuencia de colores. 


$»; 
typedef IceUtil::Handle<AlThread> AlThreadPtr; // Smart pointer. 


*tendif 


Actualmente, las responsabilidades del hilo encargado de procesar la IA del juego 
Simon son dos. Por una parte, actualizar periódicamente la secuencia de colores a repetir 
por el usuario. Esta actualización se llevaría a cabo en la función run(), pudiendo ser más 
o menos sofisticada en función del nivel de IA a implementar. Por otra parte, facilitar 
la obtención del siguiente color de la secuencia cuando el jugador haya completado la 
subsecuencia anterior. 


El siguiente listado de código muestra una posible implementación de dichas funcio- 
nes. Básicamente, el hilo de IA genera los colores de manera aleatoria, pero sería posible 
realizar una implementación más sofisticada para, por ejemplo, modificar o invertir de 
algún modo la secuencia de colores que se va generando con el paso del tiempo. 


Considere que el delay de tiempo existente entre actualización y actualización del mó- 
dulo de IA debería estar condicionado por la actual tasa de frames por segundo del juego. 
En otras palabras, la tasa de actualización del módulo de IA será más o menos exigente en 
función de los recursos disponibles con el objetivo de no penalizar el rendimiento global 
del juego. 


También es muy importante considerar la naturaleza del juego, es decir, las necesi- 
dades reales de actualizar el módulo de IA. En el caso del juego Simon, está necesidad no 
sería especialmente relevante considerando el intervalo de tiempo existente entre la gene- 
ración de una secuencia y la generación del siguiente elemento que extenderá la misma. 
Sin embargo, en juegos en los que intervienen un gran número de bots con una gran inter- 
actividad, la actualización del módulo de IA se debería producir con mayor frecuencia. 





Uso de hilos. Considere el uso de hilos cuando realmente vaya a mejorar el rendi- 
uy miento de su aplicación. Si desde el hilo de control principal se puede atender la 
lógica de IA, entonces no sería necesario delegarla en hilos adicionales. 
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Listado 7.41: AlThread::run() y AlThread::update() 





0% JO UAuWNAa 


19 


int AlThread::getColorAt (const inté index) const ( 
IceUtil::Mutex: :Lock lock(_mutex); 
return _seq[index]; 


) 


void AlThread::update () ( 
IceUtil::Mutex: :Lock lock(_mutex) |; 
// Cálculos complejos del módulo de IA. 
-seq.push_back(rand() %4); 

) 


void AlThread::run () 4 
while (true) ( 
// Calcular nueva secuencia... 
std::cout << "Updating..." << std::endl; 
update(); 
IceUtil::ThreadControl::sleep(_delay); 
) 
y 


La siguiente figura muestra el diagrama de interacción que refleja la gestión del hilo de 


IA desde la clase principal MyApp (en este ejemplo no se considera el esquema discutido 
en la sección 6.1.4 relativo a los estados de juego con Ogre). Como se puede apreciar, 
desde dicha clase principal se crea la instancia de AlThread y se ejecuta la función start(). 
A partir de ahí, el hilo continuará su ejecución de acuerdo al comportamiento definido en 
su función run(). 





: MyApp 
] 
[] created : AlThread 
— ea 
] 
Il start() ! 
O a => 





update () 


¡ getColorAt (int index) l 


| 
update_state (TState new) y 
E T 
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Típicamente, el módulo de IA actualizará parte del estado del juego en cuestión, en 
función de las características de éste. Por ejemplo, en un juego de acción, el comporta- 
miento internos de los personajes, implementado en el módulo de IA, gobernará parte de 
las acciones de los mismos, como por ejemplo la disposición para avanzar físicamente 
hacia un objetivo. Evidentemente, este tipo de acciones implican una interacción con el 
motor gráfico. 


El siguiente listado de código muestra la parte de la clase MyApp desde la que se crea 
el hilo responsable del procesamiento de la IA. 


Note cómo en este ejemplo se utiliza la función detach() para desligar el hilo de la IA 
respecto del hilo de control principal. Este planteamiento implica que, para evitar com- 
portamientos inesperados, el desarrollador ha de asegurarse de que el hijo previamente 
desligado termine su ejecución antes de que el programa principal lo haga. En el código 
fuente desarrollado esta condición se garantiza al utilizar el manejador /ceUtil::Handle 
para la clase AlThread. 


Listado 7.42: MyApp::start(); creación de AlThread 





int MyApp::start() £ 
_root = new Ogre: :Root(); 
if(!_root->restoreConfig()) 
t 
_root->showConfigDialog(); 
_root->saveConfig(); 


) 


0 JO UAUNA 


9 -AI = new AlThread(IceUtil:: Time: :seconds(1)); 
10 IceUtil::ThreadControl tc = _AI->start(); 

11 // Se desliga del hilo principal. 

12 tc.detach(); 

13 

14 TOS 





Rendimiento con hilos. El uso de hilos implica cambios de contexto y otras ope- 
wy raciones a nivel de sistema operativo que consumen miles de ciclos de ejecución. 
Evalúe siempre el impacto de usar una solución multi-hilo. 
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